"I dont know what I am doing"-Chapter 23: # "ou=" vs "cn="? Hardcoded "admin" lookup? Because the acme-ldap.jar WORKS with role discovery (bill gets ROLE_ADMIN): - I have changed the acme-ldap.jar to use "cn=users" and "cn=groups" instead of "ou=users" and "ou=groups". Works well just like before. - I have renamed "cn=users" to "cn=users1" and "cn=admins" to "cn=admins2", the user bill now gets Granted Authorities=[ROLE_AUTHENTICATED, ROLE_ADMIN2]`.
So there is no hardcoded logic to look for "ou=" instead of "cn=" somewhere and neither something hardcoded on a specific "admin" group name. # ACME structure vs our structure Unfortunately I did not manage to reconstruct a minimal example of our structure using the code of acme-ldap.jar because it seems like our LDAP uses many "auxiliary" objectClass things and I am too stupid to add those in the code. :\ Otherwise I would gladly provide a acme-ldap.jar that reproduces our structure for debugging ## Our structure, as shown in Apache Directory Studio - dc=argh,dc=org - cn=groups - cn=services - cn=thingiwantasrole with these attributes (and more): - objectClass=posixGroup - objectClas=univentionGroup - objectClass=... - cn=thingiwantasrole - memberUid=foo - memberUid=bar - uniqueMember=uid=foo,cn=... - uniqueMember=uid=bar,cn=... - ... - cn=... - cn=users - cn=admins - uid=foo with these attributes (and more): nd more): - objectClass=organizationalPerson - objectClass=person - objectClass=posixAccount - objectClass=top - objectClass=univentionObject - objectClass=... - cn=Foo Oof - uid=foo - displayName=Foo Off - ... - uid=bar - ... - uid=... - ... - cn=... ## Default acme-ldap.jar structure, as shown in Apache Directory Studio - dc=acme,dc=org - ou=groups (objectClass=organizationalRole, objectClass=top) - cn=admin with these attributes: - objectClass=groupOfNames - objectClass=top - cn=admin - member=uid=bill,ou=people,dc=acme,dc=org - cn=user - objectClass=groupOfNames - objectClass=top - cn=user - member=uid=alice,ou=people,dc=acme,dc=org - member=uid=bob,ou=people,dc=acme,dc=org - ou=people - uid=alice with these attributes: - objectClass=inetOrgPerson - objectClass=organizationalPerson - objectClass=person - objectClass=top - cn=Alice - sn=Alice - displayName=Alice - givenName=Alice - uid=alice - userPassword=Plain text password - uid=bill - ... - uid=bob - ... ## Differences - acme has all users in one directory, we have subdirectories - acme has the groups directly below groups ("cn=admin,ou=groups"), we have an additional directory subtree ("cn=thingiwantasrole,cn=services,cn=groups") - acme uses "member" as attribute name, we use "memberUid" or "uniqueMember" (one is the UID, the other the full DN(?) of the user) - acme's groups are "objectClass=groupOfNames", while ours have various different attributes like "posixGroup" and "univentionGroup" # More - The `DEBUG [security.ldap] - Roles from search: ...` line does not appear with acme, yet bill gets ROLE_ADMIN! This seems like a great hint but I have not managed to find anything useful by tracing back the functions called before that. - Using python-ldap I can use the same code and logic to discover the groups with the acme as well as our LDAP: ``` import ldap # python-ldap, https://www.python-ldap.org server = "ldap://localhost:10389/" dn = "uid=bob,ou=people,dc=acme,dc=org" password = "secret" connection = ldap.initialize(server) connection.simple_bind_s(dn, password) result = connection.search_s( base="ou=groups,dc=acme,dc=org", scope=ldap.SCOPE_SUBTREE, filterstr="(&(objectClass=groupOfNames)(member=uid=bill,ou=people,dc=acme,dc=org))", attrlist=["cn"], ) print([r[1] for r in result]) ``` gives me `[{'cn': [b'admin']}]`. Using our server host with - dn = "uid=foo,cn=admins,cn=users,dc=argh,dc=org" - base="cn=groups,dc=argh,dc=org", - filterstr="(&(objectClass=univentionGroup)(uniqueMember=uid=foo,cn=admins,cn=users,dc=argh,dc=org))", gives me `[{'cn': [b'thingiwantasrole']}, {'cn': [b'anothergroup']}]`. ----- Thanks for reading! I hope the mailing list did not ruin the formatting too much. Maybe someone has more or better ideas how to continue the search :) Cheers, Hannes hk.ihatemailingli...@enjoys.it schrieb am 29.02.2024 10:49 (GMT +01:00): > Thank you César! > > If it works for you, that is great news. > > Thank you for sharing censored information with me in private. I spotted a > small difference: > > In your (working) case there is "ou=users" and "ou=groups" while in my case we > have "cn=users" and "cn=groups". > The acme-ldap.jar from > https://docs.geoserver.org/stable/en/user/security/tutorials/ldap/index.html#ldap-server-setup > also uses "ou=groups" and worked in my tests. > > I will try to recompile acme-ldap.jar and changing its structure to > "cn=groups" > to see if that still works. > > Maybe Spring (or GeoServer in some hidden place) is really adamant on some > specific CN structure? I looked around and the "group search base" always > looks > completely configurable even if it usually uses a "ou=..." thing in examples. > - > https://docs.spring.io/spring-security/site/docs/4.0.x/reference/html/ldap.html#loading-authorities > (4) > - > https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html > (4) > - > https://docs.spring.io/spring-security/site/docs/6.1.6-SNAPSHOT/api/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html > (6, identical to 4) > > Cheers, Hannes _______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users