"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

Reply via email to