"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
[email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
