iF.SVNAdmin
iF.SVNAdmin copied to clipboard
mfreiholz
LDAP group provider - configuration issue
Hi,
I am using an groupOfUniqueNames objectClass as a group. What should be the values provided in the iF.SVNAdmin configuration? "Groups to user attribute" and "Groups to user attribute value" When I invoke Test application finds groups but when I view them there are no users displayed.
All the best Tomasz Krzysztof
Hi
Did you hit the synchronize button? It will synchronize the user with its groups.
There is also a script which can ne used with cron or scheduled task.
----- Ursprüngliche Nachricht ----- Von: "tzieleniewski" [email protected] Gesendet: 26.02.2015 11:35 An: "mfreiholz/iF.SVNAdmin" [email protected] Betreff: [iF.SVNAdmin] LDAP group provider - configuration issue (#87)
Hi, I am using an groupOfUniqueNames objectClass as a group. What should be the values provided in the iF.SVNAdmin configuration? "Groups to user attribute" and "Groups to user attribute value" When I invoke Test application finds groups but when I view them there are no users displayed. All the best Tomasz Krzysztof — Reply to this email directly or view it on GitHub.
Yes I did. My settings are: Groups to user attribute: uniqueMember Groups to user attribute value: dn
If those settings are right, you might try to append dn to [Users:ldap]/Attributes and [Groups:ldap]/Attributes. In some cases its required to fetch those attributes separately in search result, if they are not included by default.
[Users:ldap]
Attributes=sAMAccountName,dn
[Groups:ldap]
Attributes=sAMAccountName,dn
Unfortunately no progress. I only see a PHP Warning:
[Thu Feb 26 17:00:59 2015] [error] [client 10.27.224.207] PHP Warning: ldap_control_paged_result_response(): No server controls in result in /home/svn/admin/1.6.2/include/ifcorelib/IF_AbstractLdapConnector.class.php on line 311,
Already had this problem in another issue. It was due to a wrong configuration. Can you post a screenshot of the available LDAP attribute structure for a user and group, please?
See here for example: https://github.com/mfreiholz/iF.SVNAdmin/issues/53#issuecomment-30406066
It does look correct.
Maybe you can post your complete config.ini with removed passwords? :-)
Otherwise i'm running out of ideas. Especially due to the fact that you can see users and groups and only the association is missing.
Config.ini attached.
[Common] FirstStart=0 BackupFolder=./data/backup/ [Translation] Directory=./translations/ [Engine:Providers] AuthenticationStatus=basic UserViewProviderType=ldap UserEditProviderType= GroupViewProviderType=ldap GroupEditProviderType= AccessPathViewProviderType=svnauthfile AccessPathEditProviderType=svnauthfile RepositoryViewProviderType=svnclient RepositoryEditProviderType=svnclient [ACLManager] UserRoleAssignmentFile=./data/userroleassignments.ini [Subversion] SVNAuthFile=/home/svn/repos/authz [Repositories:svnclient] SVNParentPath=/home/svn/repos SvnExecutable=/usr/bin/svn SvnAdminExecutable=/usr/bin/svnadmin [Users:passwd] SVNUserFile=/home/svn/repos/passwd [Users:digest] SVNUserDigestFile= SVNDigestRealm=SVN Privat [Ldap] HostAddress=ldap://localhost:389/ ProtocolVersion=3 BindDN=*** BindPassword=*** CacheEnabled=false CacheFile=./data/ldap.cache.json [Users:ldap] BaseDN=ou=Accounts,.. SearchFilter=(objectClass=inetOrgPerson) Attributes=uid,dn [Groups:ldap] BaseDN=ou=Subversion,.. SearchFilter=(objectClass=groupOfUniqueNames) Attributes=cn,dn GroupsToUserAttribute=uniqueMember GroupsToUserAttributeValue=dn [Update:ldap] AutoRemoveUsers=true AutoRemoveGroups=true [GUI] RepositoryDeleteEnabled=false RepositoryDumpEnabled=false AllowUpdateByGui=true
Hm.. i had one rare case with OpenLDAP, where the dn wasn't fetched. Instead it was called distinguishedName. You could try that instead of dn. Beside that everything looks good to me.
No more ideas without detailed "print()" debugging, sorry. :-(
I have I clue in the LDAP log, when I synchronize application data with LDAP :)
First search finds the group. The second search, as I expect, should look for members according to the pointed user attribute. In such situation filter seems strange as it uses uid-*. I think it should be the pointed dn, isn't it?
When actually iF.SVNAdmin is querying the LDAP provider to fill groups with users? I can catch LDAP log during that time and see what is happening.
Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=2 SRCH base="ou=Subversion,.." scope=2 deref=0 filter="(objectClass=groupOfUniqueNames)" Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=2 SRCH attr=cn uniqueMember Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=3 SRCH base="ou=Accounts,.." scope=2 deref=0 filter="(&(uid=*)(objectClass=inetOrgPerson))" Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=3 SRCH attr=uid Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=3 SEARCH RESULT tag=101 err=4 nentries=1 text= Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 op=4 UNBIND Mar 5 17:14:31 tmatest slapd[2426]: conn=1073 fd=22 closed
Sorry, was kinda busy. :-)
The log tells you about an error 4, which means "size limit exceeded", based on OpenLDAP documentation.
The "Synchronize" does following actions in that order:
- Get all users
- Get all groups Yes, its currently not very efficient.
It looks like that the problem is based on the too big result => too many groups to fetch them all at once. But it's possible to configure the server to allow a higher limit. How many groups do you currently have anyway?
Manuel
The thing is... the synchronize-function doesn't do any searches for members in groups. It retrieves all users and groups (+ their mapping attributes) and maps them manually by comparing those attributes. I used that way to reduce the number of LDAP searches.
So if you have a lot of users, groups and member-mappings this might lead to a big search result (probably some mega bytes).
I really should change this to a more efficient way. Better slow but stable. :-|
I am testing this on the test system, I have 8 users and only one group :)
The problem could also be related to the * user. Do you have at any repository an assignment to the ALL (*) user?
[myrepo:/blah/blubb]
*=r
Can you try to remove them, please? That would be a very critical bug. Sorry, i can't try it right now.
I will also try it myself and fix it ASAP - tomorrow ;)
Sent from mobile. Am 10.03.2015 22:47 schrieb "tzieleniewski" [email protected]:
Yes I have. I'll check it tomorrow.
— Reply to this email directly or view it on GitHub https://github.com/mfreiholz/iF.SVNAdmin/issues/87#issuecomment-78155443 .
I'm 99.99% sure that i just found and fixed the problem. :-)
In case your are running the current git MASTER (1.6.3 UNOFFICIAL) you can download and replace this file only: https://github.com/mfreiholz/iF.SVNAdmin/blob/master/classes/providers/ldap/LdapUserViewProvider.class.php Otherwise i would recommend to update to the current MASTER.
Works :) Thanks! Manuel I've also copied the CachedLdapUserViewProvider.class.php file.
Remark: the main window "Update (Synchronize)" tab has disappeared, is this correct?
No, it should be visible. My guess: Not all of your files are from the current MASTER. I would suggest to update your entire installation with the current GitHub MASTER. I just tested it and i can see the button.
Btw.. After you enabled the Cache you will not see any user or group -> Update->Sync is required.
FYI.. You can run the sync job via command line by CRON (Linux) or Scheduled Task (Windows).
Thanks! When do you plan to release the next version including those changes?
Probably soon. But I'm currently working on a entire rebuild of the application. The current Master will only get bug fixes - no more features. That means.. The current master is as good as every release. ;)
Sent from mobile. Am 11.03.2015 14:52 schrieb "tzieleniewski" [email protected]:
Thanks! When do you plan to release the next version including those changes?
— Reply to this email directly or view it on GitHub https://github.com/mfreiholz/iF.SVNAdmin/issues/87#issuecomment-78266157 .