Help with Account disabled test and Open LDAP(Novell)

[cforce]

In our user entry we have an attrib "loginDisabled" = "true" or "lockedByIntruder"=true if account is locked.

Howto use this with the plugin?

[cforce]

Its buggy: rake redmine:plugins:redmine_ldap_sync:sync_users ACTIVATE_USERS=1 RAILS_ENV=production --trace

* Invoke redmine:plugins:redmine_ldap_sync:sync_users (first_time) * Invoke environment (first_time) * Execute environment * Execute redmine:plugins:redmine_ldap_sync:sync_users Synchronizing AuthSource ldap... rake aborted! undefined method downcase' for nil:NilClass /home/sidfunktion/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/set.rb:222:inblock in each' /home/sidfunktion/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/set.rb:222:in each_key' /home/sidfunktion/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/set.rb:222:ineach' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:152:in map' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:152:inldap_users' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:44:in sync_users' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:23:inblock (5 levels) in <top (required)>' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:21:in each' /home/sidfunktion/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:21:inblock (4 levels) in <top (required)>' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:228:in call' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:228:inblock in execute' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:223:in each' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:223:inexecute' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:166:in block in invoke_with_call_chain' /home/sidfunktion/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/monitor.rb:211:inmon_synchronize' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:159:in invoke_with_call_chain' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:152:ininvoke' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:143:in invoke_task' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:inblock (2 levels) in top_level' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:in each' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:inblock in top_level' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:110:in run_with_threads' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:95:intop_level' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:73:in block in run' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:160:instandard_exception_handling' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:70:in run' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/bin/rake:33:in<top (required)>' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/bin/rake:23:in load' /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/bin/rake:23:in

' Tasks: TOP => redmine:plugins:redmine_ldap_sync:sync_users

[thorin]

With or without account_flags configured?

That error means some of the users don't have 'cn'.

[cforce]

With account_flags set

flags = 'TRUE'

What yo you mean with "some of the users" ? The test user 1276 we spoke all the timei yet checked and it has a cn.

[thorin]

You setup is behaving completely random... :( I'll do something to prevent the nilClass error. But that error shouldn't be happening at all.

The list of users shouldn't contain 'nil's at all. So that downcase on a nil error means that it is not being able to retrieve the users correctly from ldap.

[thorin]

if you place a puts changes.inspect before line 152 you'll see that the sets contains nils... It means that find_all_users is generating entries without the user login.

Yesterday we didn't had that error and I haven't changed that part of the code... :(

[thorin]

Might be because of the net-ldap patch. Try disabling it on init.rb.

[cforce]

Wait, i made a clean clone and removbed myslf fixed net-ldap patch in favour of yours. Now the task runs, but user 1276 i still locked

rake redmine:plugins:redmine_ldap_sync:sync_users ACTIVATE_USERS=1 RAILS_ENV=production --trace

* Invoke redmine:plugins:redmine_ldap_sync:sync_users (first_time) * Invoke environment (first_time) * Execute environment * Execute redmine:plugins:redmine_ldap_sync:sync_users Synchronizing AuthSource dsv-ldap... -- Found 320 users active, 1417 locked and 0 deleted on ldap ..... -- Locked active user '00001276' ..... Above entry is the only witch macthes consoel output for "1276" string match

I migrated to redmine 2.2.3 in the meantime

[cforce]

For undertanding you first go through a look to lock users, then unlock users. That would explain the hundreds of -- Not locking locked user 'userid'

strings in the first place

[thorin]

My guess is that this is an encoding problem. I would like to try to recreate the problem on my lap. I'll need an example of an user's first name, last name, and login.

The most important thing is to know if any of those fields have non ASCII characters.

I will also need to know what is the encoding that is being used by ruby and by novell edirectory. For that I'll try to give you some directions later.

[thorin]

Can you confirm that you are using ruby 1.9? I believe the problems with net_ldap and the encoding errors started showing up with this version of ruby.

--- For ruby 1.9 you can do the following to get the encodings:

redmine# rails console RAILS_ENV=production
Encoding.find('internal')
Encoding.find('external')
Encoding.find('locale')
Encoding.find('filesystem')
Encoding.locale_charmap

-- I'll also need the encoding of the database: For Mysql: show variables like "%char%"; For postgresql (on the redmine's production db): SHOW SERVER_ENCODING;

-- I believe that Novell eDirectory only works with UTF-8 internally and that is not possible to change Can you confirm it?

[cforce]

Can you confirm that you are using ruby 1.9?

ruby 1.9.3p327 (2012-11-10 revision 37606) [i686-linux]

Loading development environment (Rails 3.2.12) irb: warn: can't alias help from irb_help. 1.9.3-p327 :001 > Encoding.find('internal') => #Encoding:UTF-8 1.9.3-p327 :002 > Encoding.find('external') => #Encoding:UTF-8 1.9.3-p327 :003 > Encoding.find('locale') => #Encoding:UTF-8 1.9.3-p327 :004 > Encoding.find('filesystem') => #Encoding:UTF-8 1.9.3-p327 :005 > Encoding.locale_charmap => "UTF-8" 1.9.3-p327 :006 >

show variables like "%char%" 'character_set_client' 'utf8' 'character_set_connection' 'utf8' 'character_set_database' 'utf8' 'character_set_filesystem' 'binary' 'character_set_results' '' 'character_set_server' 'utf8' 'character_set_system' 'utf8' 'character_sets_dir' '/usr/share/mysql/charsets/'

I believe that Novell eDirectory only works with UTF-8 internally and that is not possible to change

Sorry, i am just no idea, Our admin also don't know how to find out, bad ins't it?

[cforce]

Ok i finally found out the ldap server is UTF-8. (LC_CTYPE=en_US.UTF-8.)

[thorin]

ok, All I need now is an example of a user that fails to synchronize.

You told me it fails to enable your user. Does your user have non-ascii letters on the login, firstname or lastname?

[thorin]

After giving me an example you can try changing the file lib / redmine_ldap_sync / core_ext / string_patch.rb to the following:

module RedmineLdapSync::CoreExt::StringPatch
  def raw_utf8_encoded
    return self

    if self.respond_to?(:encode)
      # Strings should be UTF-8 encoded according to LDAP.
      # However, the BER code is not necessarily valid UTF-8
      # self.encode('UTF-8', invalid: :replace, undef: :replace, replace: '' ).force_encoding('ASCII-8BIT')
      begin
        self.encode('UTF-8').force_encoding('ASCII-8BIT')
      rescue Encoding::UndefinedConversionError
        self
      end
    else
      self
    end
  end
  private :raw_utf8_encoded
end

I'm starting to suspect that this convertion might not be needed. But, if it doesn't work, please revert it back to the way it was.

[cforce]

You told me it fails to enable your user.

Yes, thats correct.

Does your user have non-ascii letters on the login, firstname or lastname?

Nope, he doesn't

• id is 0-9
• all names are a-Z
• no Umlaute and no german special jars, like "ß"

With ur above patch i get the encoding error again ;/

rake redmine:plugins:redmine_ldap_sync:sync_users ACTIVATE_USERS=1 RAILS_ENV=production --trace

* Invoke redmine:plugins:redmine_ldap_sync:sync_users (first_time) * Invoke environment (first_time) * Execute environment * Execute redmine:plugins:redmine_ldap_sync:sync_users Synchronizing AuthSource dsv-ldap... rake aborted! incompatible character encodings: ASCII-8BIT and UTF-8 /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ber/core_ext/array.rb:62:in to_ber_seq_internal' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ber/core_ext/array.rb:54:into_ber_contextspecific' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ldap.rb:1398:in block in search' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ldap.rb:1367:inloop' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ldap.rb:1367:in search' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/net-ldap-0.3.1/lib/net/ldap.rb:637:insearch' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:297:in ldap_search' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:289:infind_all_users' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:142:in ldap_users' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/redmine_ldap_sync/redmine_ext/auth_source_ldap_patch.rb:44:insync_users' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:23:in block (5 levels) in <top (required)>' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:21:ineach' /home/user/DevMine_WK/infomine-2.2/plugins/redmine_ldap_sync/lib/tasks/sync_users.rake:21:in block (4 levels) in <top (required)>' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:228:incall' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:228:in block in execute' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:223:ineach' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:223:in execute' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:166:inblock in invoke_with_call_chain' /home/user/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/monitor.rb:211:in mon_synchronize' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:159:ininvoke_with_call_chain' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/task.rb:152:in invoke' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:143:ininvoke_task' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:in block (2 levels) in top_level' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:ineach' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:101:in block in top_level' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:110:inrun_with_threads' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:95:in top_level' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:73:inblock in run' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:160:in standard_exception_handling' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/lib/rake/application.rb:70:inrun' /home/user/.rvm/gems/ruby-1.9.3-p327/gems/rake-10.0.3/bin/rake:33:in <top (required)>' /home/user/.rvm/gems/ruby-1.9.3-p327/bin/rake:23:inload' /home/user/.rvm/gems/ruby-1.9.3-p327/bin/rake:23:in `

' Tasks: TOP => redmine:plugins:redmine_ldap_sync:sync_users

[cforce]

Maybe the problem are other ldap attribs, like groups or description. There i have Umlaute and special Chars which are know not to be supported well from some ldap clients, although shall be asci. See http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=467831

We had problem with the "§" char in password for examle, however that is another client setup with http browser frontend and apache moddav passthrough for ldap auth.

How shall i support you best to find the attrib/chars maybe making issue? Can a charsez problem somwhere in attrib stream break out and affect other attrib, the wehole record for the user resulting in getting locked? However the example user making troubles jas no password with speical chars either. Password also is a-Z, no Umlaute and no german special jars, like "ß" or "§"

[thorin]

That is an option, but I don't believe it is the case. A second option is that the conversion between enconding is messing up the search which ends in the user not being found on LDAP. If the user is not found, it ends up being locked.

I'll give you some other code to test.

[thorin]

Please try the following code:

module RedmineLdapSync::CoreExt::StringPatch
  def raw_utf8_encoded
    if self.respond_to?(:encode)
      # Strings should be UTF-8 encoded according to LDAP.
      # However, the BER code is not necessarily valid UTF-8
      # self.encode('UTF-8', invalid: :replace, undef: :replace, replace: '' ).force_encoding('ASCII-8BIT')
      if (self.encoding.name == 'UTF-8')
        self.force_encoding('ASCII-8BIT')
      else
        self
      end
    else
      self
    end
  end
  private :raw_utf8_encoded
end

This should prevent raw_utf8_encoded to be applied to control strings. Those strings should already be in ASCII-8BIT and we don't want to mess them by converting them to UTF-8.

[cforce]

Nothing changed, user get locked again / not unlocked.

[thorin]

Ok, I'll keep trying to reproduce the error on my ldap. I've been moving half blind and right now I have no clue of what might be causing the problem.

By default, redmine only allows ascii characters on the login. (/\A[a-z0-9_\-@\.]*\z/i) Do you have any modification or plugin that could have changed this default?

[cforce]

By default, redmine only allows ascii characters on the login. (/\A[a-z0-9_-@.]*\z/i)

The user don't get registed from redmine and pushed into ldap, but created in ldap and synced into redmine. The user data is read only from redmine site and data i created with some (unknown) other ldap client via enterprise paper based process and manual work.

Do you have any modification or plugin that could have changed this default?

The data is not created via redmine ,s o it shouldn't maptter, but i don't know ones of the plugin i use to do stgh in this direction.

[thorin]

I was stating it because when synchronizing the users are created on the redmine's DB. If somehow this filter was changed it would allow those users with non-ascii logins to be created on the database.

If this was not changed redmine_ldap_sync would give an error because redmine wouldn't allow such a user to be created on the DB.

My concern is just to know if I should or not test users with non-ascii characters on the login. If no changes were made to the filter it makes no sense for me to test it.

[cforce]

Hm i still don't understand. The user are manually created either via register or Admin>User>New from Redmine Admin. So you think a plugin could patch the view or controller and entered nonascii chars instead redmine core class which don't. Why redmine doesn't allow any utf8 for users data if mysql allows utf8. Why don't ur plugin uses utf8 and tries to convert from here to there. If such problems would exist, why can i log in regular in redmine and get authenticated correctly without problems? The decision "get lcoked" or get "unlocked" shall evaluate only one ldap attrib to true or false, and then set the model flag according. Maybe we have to check there again. That the only thinh i see so far doesn't work. Why could so much other code now could be resonsible for this issue?

[thorin]

As I said, my question is only to help me know what I should test. I'm not pushing the responsibility to another plugin.

So you think a plugin could patch the view or controller and entered nonascii chars instead redmine core class which don't. No, it's neither a view nor a controller. It is the User model.

Every time a user is saved on the database, it as to go through the validations on the user model. One of the validations is that the login can only have ascii characters (the regex /\A[a-z0-9_-@.]*\z/i).

Both on login (on-the-fly), or by synchronization, it as to cross the User model to save the user on the local database. If the validation fails an error is raised and it stops the user from being created.

Yes, it is possible to patch this validation on a plugin if you want to be less restrictive on the logins that you want to allow.

From the tests we've made, I believe there is no problems with evaluation but with finding the users on the ldap. As you told me the users_on_ldap variable was missing some users.

If a user is missing on ldap it also ends getting locked.

If such problems would exist, why can i log in regular in redmine and get authenticated correctly without problems?

I don't know. I have to do tests. The plugin searches for users using ldap calls different from those used by redmine.

[cforce]

Do you query for all users of given class and in given BASE DN? Is thats the code which return not all users, than here is the error. So i could maybe aks my admin to live debug my ldap query on server side and find out why user onjects are no returned. Or do you think the plugin can no well deserilaize the retunred ldap query result?

[thorin]

I believe there is some problem deserializing the query result because we have seen that some of the users are missing the cn attribute.

But if will help if the ldap admin could tell us what's query that is reaching the LDAP, how many users it is returning and if the locked users are in it.

The plugin does a query for the attributes cn and loginDisabled of the entries on base dn (O=D...) with the given objectClass (organizationalPerson) .

[cforce]

For debugging on server side it would help only this problemtic query will be send. Are there other queries the script does, and how could i reduce bit only do the query do test.

[cforce]

For the record i must really thank you for this strong support and interest to find the issue. I really hope it doesn't turn out to be a false positive because me overseeing stgh. nothing todo with the plugin code. I am really thank full because the i need the plugin to get rid of the manuals user managment tasks in our growing user base. Thakns that you such fullblooded opensource enthusiast. ;)

[thorin]

Yes, there are other queries. If you want to reduce the number of queries sent by the plugin you can introduce an error at the end of the ldap_users method. For example, by adding nil to the end of the method and then execute the rake synchronization task.

          def ldap_users
            return @ldap_users if @ldap_users

            ldap_con = initialize_ldap_con(self.account, self.account_password)
            changes = {:enabled => Set.new, :disabled => Set.new}

            if settings[:account_flags].blank?
              changes[:enabled] = find_all_users(ldap_con, [:login])
            else
              find_all_users(ldap_con, [:login, :account_flags]) do |entry|
                if account_disabled?(entry[:account_flags])
                  changes[:disabled] << entry[:login] if entry[:login]
                else
                  changes[:enabled] << entry[:login] if entry[:login]
                end
              end
            end

            users_on_local  = self.users.active.map {|u| u.login.downcase }
            users_on_ldap   = changes.values.sum.map(&:downcase)
            deleted_users   = users_on_local - users_on_ldap
            changes[:disabled]  += deleted_users

            msg = "-- Found #{changes[:enabled].size} users active"
            msg << ", #{changes[:disabled].size - deleted_users.size} locked"
            msg << " and #{deleted_users.size} deleted on ldap"
            puts msg

            @ldap_users = changes
            nil # This will cause an undefined method '[]' for nil:NilClass Error
          end

Thank you for your thanks. I really appreciate it.

PS: I hope that with the next version of the plugin it becomes easier to configure and test all this ldap settings.

[cforce]

I nearly found the cause. IT's the method account_disabled which returns 'TRUE' for '00001276's 'account_flags=FALSE' and the configured account deativation condition "flags = 'TRUE'"

Debug Code:

def ldap_users return @ldap_users if @ldap_users

        ldap_con = initialize_ldap_con(self.account, self.account_password)
        changes = {:enabled => Set.new, :disabled => Set.new}

        if settings[:account_flags].blank?
          changes[:enabled] = find_all_users(ldap_con, [:login])
        else
          find_all_users(ldap_con, [:login, :account_flags]) do |entry|
            if entry[:login]== '00001276'
              puts "debug user 00001276 #{entry.inspect}"
              puts "00001276 account_disabled #{account_disabled?(entry[:account_flags])}"
            end
            if account_disabled?(entry[:account_flags])
              changes[:disabled] << entry[:login] if entry[:login]
            else
              changes[:enabled] << entry[:login] if entry[:login]
            end
          end
        end

        users_on_local  = self.users.active.map {|u| u.login.downcase }
        puts "-- Found user 00001276 on users_on_local is #{!users_on_local.select {|s| s.include? '00001276'}.nil?}"
        users_on_ldap   = changes.values.sum.map(&:downcase)
        puts "-- Found user 00001276 on users_on_ldap is #{!users_on_ldap.select {|s| s.include? '00001276'}.nil?}"
        deleted_users   = users_on_local - users_on_ldap
        puts "-- deleted_users is #{deleted_users.inspect}"
        changes[:disabled]  += deleted_users
        puts "-- changes[:disabled] for 00001276 is #{changes[:disabled].select {|s| s.include? '00001276'}.inspect}"

        msg = "-- Found #{changes[:enabled].size} users active"
        msg << ", #{changes[:disabled].size - deleted_users.size} locked"
        msg << " and #{deleted_users.size} deleted on ldap"
        puts msg

        @ldap_users = changes
        nil # This will cause an undefined method '[]' for nil:NilClass Error
      end

Output: /.rvm/rubies/ruby-1.9.3-p327/bin/ruby -e at_exit{sleep(1)};$stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) /home/sidfunktion/.rvm/gems/ruby-1.9.3-p327/gems/ruby-debug-ide-0.4.17.beta16/bin/rdebug-ide --port 45121 --dispatcher-port 50448 -- /.rvm/gems/ruby-1.9.3-p327/bin/rake redmine:plugins:redmine_ldap_sync:sync_users ACTIVATE_USERS=1 --trace Fast Debugger (ruby-debug-ide 0.4.17.beta16, ruby-debug-base19x 0.11.30.pre11) listens on 127.0.0.1:45121 Fast Debugger (ruby-debug-ide 0.4.17.beta16, ruby-debug-base19x 0.11.30.pre11) listens on 127.0.0.1:56501

* Invoke redmine:plugins:redmine_ldap_sync:sync_users (first_time) * Invoke environment (first_time) * Execute environment * Execute redmine:plugins:redmine_ldap_sync:sync_users Synchronizing AuthSource dsv-ldap... debug user 00001276 {:user_memberid=>"cn=00001276,ou=S,o=DSV", :account_flags=>"FALSE", :login=>"00001276", :groupname=>"00001276"} 00001276 account_disabled TRUE -- Found user 00001276 on users_on_local is true -- Found user 00001276 on users_on_ldap is true -- deleted_users is [] -- changes[:disabled] for 00001276 is ["00001276"] -- Found 321 users active, 1421 locked and 0 deleted on ldap

Result:

def account_disabled?(flags) ............... return @account_disabled_test.call(flags) if @account_disabled_test > RETURNS TRUE !!!!!!!

[thorin]

Nice work.

Have you changed the case of the 'true' of the line: '00001276 account_disabled TRUE'? On a normal output that value is downcased.

I'll try to dig a bit deeper on that and see what might be failing. The evaluation of the expression is very straight forward and that result is quite strange?

As a side comment: The result of select is never nil. Saying so, the expression: !users_on_local.select {|s| s.include? '00001276'}.nil? will always return true. What you probably want is: users_on_local.include?('00001276')

[thorin]

Make sure you have: flags == 'TRUE'

Notice the two equals.

Sorry, it seems it was me who have driven you into the mistake of using a simple equal on the expression.

[cforce]

~ß?#.'!*` >-<

Ok, no it works. All user get activated and no mkore locked again. I already had a feeling about that is was such silly and small cfg thing and not the code. Can u please add a note an wiki to remember. This config would work for most novell ldap servers.

Tx alot

!!! CLOSED !!!

[thorin]

It was a mixture of problems. Encoding and configuration.

Thank you for your patience.