LDAP: Users do not get synced in the group they belong to

aifiedler · Aug 8, 2022

Dear Proxmox Team,

Our Proxmox Version: 7.2-7.

We are trying to setup up LDAP Authentication. It works but LDAP users don't get synced into their group.

This is our LDAP tree:

Code:

# Core-Admins, Gruppen, example, hq.example.net
dn: cn=Core-Admins,ou=Gruppen,ou=example,dc=hq,dc=example,dc=net
cn: Core-Admins
gidNumber: 5071
sambaGroupType: 2
univentionGroupType: -2147483646
sambaSID: S-1-5-21-3603376056-218413407-2892877714-11143
objectClass: univentionGroup
objectClass: univentionObject
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
univentionObjectType: groups/group
memberUid: iamauser.iamauser
memberUid: iamauser.iamauser
memberUid: iamauser.iamauser
memberUid: iamauser.iamauser
uniqueMember: uid=iamauser.iamauser,ou=benutzer,ou=example,dc=hq,dc=example,dc=net
uniqueMember: uid=iamauser.iamauser,ou=benutzer,ou=example,dc=hq,dc=example,dc=net
uniqueMember: uid=iamauser.iamauser,ou=benutzer,ou=example,dc=hq,dc=example,dc=net
uniqueMember: uid=iamauser.iamauser,ou=benutzer,ou=example,dc=hq,dc=example,dc=net

LDAP config from /etc/pve/domains.cfg

Code:

ldap: ldap
        base_dn dc=hq,dc=example,dc=net
        server1 ucs-ad.hq.example.net
        user_attr uid
        bind_dn uid=ldap-auth,dc=hq,dc=example,dc=net
        default 0
        filter memberOf=cn=Core-Admins,ou=Gruppen,ou=example,dc=hq,dc=example,dc=net
        group_filter cn=Core-Admins
        port 7636
        secure 1
        sync-defaults-options remove-vanished=acl;entry;properties,scope=users
        sync_attributes email=mailPrimaryAddress

What do we need to do in order to get this working?

Best regards

Alexander Fiedler

aifiedler · Aug 10, 2022

Any suggestions on this?

aifiedler · Aug 12, 2022

dcsapak · Aug 12, 2022

can you post the task log output of a sync (or a dry run) ?

aifiedler · Aug 12, 2022

Code:

(dry test run) starting sync for realm ldap
got data from server, updating users and groups
syncing users
remove-vanished: acl;entry;properties
deleting outdated existing users first
overwriting user 'iamauser.iamauser@ldap'
overwriting user 'iamauser.iamauser@ldap'
overwriting user 'iamauser.iamauser@ldap'
overwriting user 'iamauser.iamauser@ldap'
syncing groups
remove-vanished: acl;entry;properties
deleting outdated existing groups first
overwriting group 'Core-Admins-ldap'

NOTE: Dry test run, changes were NOT written to the configuration.
TASK OK

aifiedler · Aug 15, 2022

Any updates on this?

Stoiko Ivanov · Aug 17, 2022

@dcsapak (our resident expert on the LDAP sync) is currently out of office - but I'll try to chime in.

on a hunch - you have set

aifiedler said:
scope=users

in the default sync-options - does the behavior change if you change this to 'groups' or - probably what you want - 'both'?

I hope this helps!

aifiedler · Aug 17, 2022

Stoiko Ivanov said:
@dcsapak (our resident expert on the LDAP sync) is currently out of office - but I'll try to chime in.

on a hunch - you have set

in the default sync-options - does the behavior change if you change this to 'groups' or - probably what you want - 'both'?

I hope this helps!

Hi,

thanks for this hint. This is just the default option. If I select users AND groups(both) The users are still not added to the group they belong to.

Stoiko Ivanov · Aug 18, 2022

ok - took me a while to setup a test-setup - and I have to say - here it works.

to get to the bottom of the issue on your end please provide the output of the equivalent ldapsearches (slightly abridged):

Code:

 ldapsearch -H ldaps://ucs-ad.hq.example.net:7636 -D 'uid=ldap-auth,dc=hq,dc=example,dc=net' -b 'dc=hq,dc=example,dc=net' -W '(cn=Core-Admins)'
 ldapsearch -H ldaps://ucs-ad.hq.example.net:7636 -D 'uid=ldap-auth,dc=hq,dc=example,dc=net' -b 'dc=hq,dc=example,dc=net' -W  '(memberOf=cn=Core-Admins,ou=Gruppen,ou=example,dc=hq,dc=example,dc=net)'

I hope I got the commands right - but the ldapsearch manpage should help if you don't get any sensible output

Please do redact all sensitive information (but not more - so that we have a chance of seeing what's going on)

aifiedler · Aug 29, 2022

Hi, sorry for my late answer, but here is the output of both commands

ldapsearch -H ldaps://ucs-ad.hq.example.net:7636 -D 'uid=ldap-auth,dc=hq,dc=example,dc=net' -b 'dc=hq,dc=example,dc=net' -W '(cn=Core-Admins)'

Code:

# Core-Admins, Gruppen, example, hq.example.net

dn: cn=Core-Admins,ou=Gruppen,ou=example,dc=hq,dc=example,dc=net

cn: Core-Admins

gidNumber: 5071

sambaGroupType: 2

univentionGroupType: -2147483646

sambaSID: S-1-5-21-360334556-218435407-28345714-11143

objectClass: univentionGroup

objectClass: univentionObject

objectClass: top

objectClass: posixGroup

objectClass: sambaGroupMapping

univentionObjectType: groups/group

memberUid: user.user

memberUid: user.user

memberUid: user.user

memberUid: user.user

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net

ldapsearch -H ldaps://ucs-ad.hq.example.net:7636 -D 'uid=ldap-auth,dc=hq,dc=example,dc=net' -b 'dc=hq,dc=example,dc=net' -W '(memberOf=cn=Core-Admins,ou=Gruppen,ou=example,dc=hq,dc=example,dc=net)'

Code:

# user.user, Benutzer, example, hq.example.net

dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

krb5MaxLife: 86400

krb5MaxRenew: 604800

uid: user.user

uidNumber: 2027

givenName: User

sn: User

gecos: user user

displayName: user user

telephoneNumber: 23

homeDirectory: /home/user.user

loginShell: /bin/bash

mailForwardCopyToSelf: 0

cn: User User

krb5PrincipalName: user.user@HQ.example.NET

sambaBadPasswordCount: 0

sambaBadPasswordTime: 0

sambaAcctFlags: [U          ]

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: univentionObject

objectClass: top

objectClass: univentionPWHistory

objectClass: krb5Principal

objectClass: posixAccount

objectClass: krb5KDCEntry

objectClass: sambaSamAccount

objectClass: univentionMail

objectClass: person

objectClass: automount

objectClass: shadowAccount

sambaSID: S-1-5-21-3603376056-218413407-2892877714-5054

gidNumber: 5017

sambaPrimaryGroupSID: S-1-5-21-3603376056-218413407-2892877714-11035

univentionObjectType: users/user

shadowLastChange: 19111

street: redacted

mailPrimaryAddress: user@example.net



# user.user, Benutzer, example, hq.example.net

dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

krb5MaxLife: 86400

krb5MaxRenew: 604800

uid: user.user

uidNumber: 2028

givenName: User

sn: User

gecos: User

displayName: User User

telephoneNumber: redacted

homeDirectory: /home/user.user

loginShell: /bin/bash

mailForwardCopyToSelf: 0

cn: User user

krb5PrincipalName: user.user@HQ.example.NET

sambaBadPasswordCount: 0

sambaBadPasswordTime: 0

sambaAcctFlags: [U          ]

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: univentionObject

objectClass: top

objectClass: univentionPWHistory

objectClass: krb5Principal

objectClass: posixAccount

objectClass: krb5KDCEntry

objectClass: sambaSamAccount

objectClass: univentionMail

objectClass: person

objectClass: automount

objectClass: shadowAccount

sambaSID: S-1-5-21-3603334334-34-4-5056

gidNumber: 5017

sambaPrimaryGroupSID: S-1-5-21-3603376056-218413407-2892877714-11035

univentionObjectType: users/user

shadowLastChange: 19111

mailPrimaryAddress: user@example.net



# user.user, Benutzer, example, hq.example.net

dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

krb5MaxLife: 86400

krb5MaxRenew: 604800

uid: user@example.net

uidNumber: 2016

givenName: User

sn: User

gecos: User user

displayName: User user

homeDirectory: /home/user.user

loginShell: /bin/bash

mailForwardCopyToSelf: 0

cn: User user

krb5PrincipalName: user@example.net

sambaBadPasswordCount: 0

sambaBadPasswordTime: 0

sambaAcctFlags: [U          ]

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: univentionObject

objectClass: top

objectClass: univentionPWHistory

objectClass: krb5Principal

objectClass: posixAccount

objectClass: krb5KDCEntry

objectClass: sambaSamAccount

objectClass: univentionMail

objectClass: person

objectClass: automount

objectClass: shadowAccount

sambaSID: S-1-5-21-3603376056-218413407-2892877714-5032

gidNumber: 5017

sambaPrimaryGroupSID: S-1-5-21-3603376056-13407-2892877714-11035

univentionObjectType: users/user

shadowLastChange: 19111

mailPrimaryAddress: user@example.net



# user.user, Benutzer, example, hq.example.net

dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

krb5MaxLife: 86400

krb5MaxRenew: 604800

uid: user.user

uidNumber: 2049

givenName: User

sn:: redacted

gecos: User User

displayName::

telephoneNumber: 25

homeDirectory: /home/user.user

loginShell: /bin/bash

mailForwardCopyToSelf: 0

cn:: redacted

krb5PrincipalName: user@example.net

sambaBadPasswordCount: 0

sambaBadPasswordTime: 0

sambaAcctFlags: [U          ]

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: univentionObject

objectClass: top

objectClass: univentionPWHistory

objectClass: krb5Principal

objectClass: posixAccount

objectClass: krb5KDCEntry

objectClass: sambaSamAccount

objectClass: univentionMail

objectClass: person

objectClass: automount

objectClass: shadowAccount

sambaSID: S-1-5-21-3603376056-218413407-2892877714-5098

gidNumber: 5017

sambaPrimaryGroupSID: S-1-5-21-36033760-513407-28928-77714035

univentionObjectType: users/user

shadowLastChange: 19111

mailPrimaryAddress: user@example.net

Stoiko Ivanov · Aug 29, 2022

Just to be sure:
* you did 'anonymize' the "user.user" part - and in reality this is 3 different user-names?
* it's the same user names that are indeed listed as 'memberUid' attributes to the 'Core-Admins' object?

If this is the case - it should work - (as it does here on my system)

aifiedler · Aug 29, 2022

Stoiko Ivanov said:
Just to be sure:
* you did 'anonymize' the "user.user" part - and in reality this is 3 different user-names?
* it's the same user names that are indeed listed as 'memberUid' attributes to the 'Core-Admins' object?

If this is the case - it should work - (as it does here on my system)

Yes, this is indeed the case.

Stoiko Ivanov · Aug 29, 2022

hmm - then please post (with the same amount of anonymization - although if possible please replace user.user with user1.user1, user2.user2,... where applicable):
* /etc/pve/user.cfg
* the output of `pveum realm sync ldap -remove-vanished 'acl;properties;entry' -scope both
* /etc/pve/user.cfg (after running the sync)

aifiedler · Aug 29, 2022

Before sync; /etc/pve/user.cfg

Code:

user:root@pam:1:0:::support@example.net:::

group:Core-Admins-ldap:::

PVE LDAP Sync output:

Code:

starting sync for realm ldap
got data from server, updating users and groups
syncing users
remove-vanished: acl;properties;entry
deleting outdated existing users first
adding user 'user1.user1@ldap'
adding user 'user2.user2@ldap'
adding user 'user3.user3@ldap'
adding user 'user4.user4@ldap'
syncing groups
remove-vanished: acl;properties;entry
deleting outdated existing groups first
overwriting group 'Core-Admins-ldap'
successfully updated users and groups configuration

And finally the /etc/pve/user.cfg again after the sync:

Code:

user:user1.user1@ldap:1:0:::user1@example.net:::
user:user2.user2@ldap:1:0:::user2@example.net:::
user:user3.user3@ldap:1:0:::user3@example.net:::
user:root@pam:1:0:::support@example.net:::
user:user4.user4@ldap:1:0:::user4@example.net:::

group:Core-Admins-ldap:::

Stoiko Ivanov · Aug 29, 2022

Thanks - I have a hunch at where the issue might be:

Code:

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net
vs.
dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

the case of 'benutzer' vs. 'Benutzer'

any chance to change that to be consistent on your end?

I need to take a closer look, but I think we might need to switch to a case-insensitive match based on a quick glance at:
https://ldapwiki.com/wiki/Distinguished Name Case Sensitivity

aifiedler · Aug 29, 2022

Stoiko Ivanov said:
Thanks - I have a hunch at where the issue might be:

Code:

uniqueMember: uid=user.user,ou=benutzer,ou=example,dc=hq,dc=example,dc=net vs. dn: uid=user.user,ou=Benutzer,ou=example,dc=hq,dc=example,dc=net

the case of 'benutzer' vs. 'Benutzer'

any chance to change that to be consistent on your end?

I need to take a closer look, but I think we might need to switch to a case-insensitive match based on a quick glance at:
https://ldapwiki.com/wiki/Distinguished Name Case Sensitivity

Thanks for checking on it, I now noticed that too.

I need to check with my colleagues but I don't think we can change "benutzer" easily now.

aifiedler · Aug 29, 2022

@Stoiko Ivanov

Can you provide me with a proof of concept line of code that would implement a case-insensitive match?

Stoiko Ivanov · Aug 29, 2022

I sent an initial patch for this to the pve-devel list:
https://lists.proxmox.com/pipermail/pve-devel/2022-August/053803.html

if you can - please try it and provide feedback.

I'll try to update this thread once this patch or an improved version is available on our public test repositories

aifiedler · Aug 30, 2022

Stoiko Ivanov said:
I sent an initial patch for this to the pve-devel list:
https://lists.proxmox.com/pipermail/pve-devel/2022-August/053803.html

if you can - please try it and provide feedback.

I'll try to update this thread once this patch or an improved version is available on our public test repositories

Thanks for the patch. I'll try to change these lines in the code and give you feedback.

aifiedler · Aug 30, 2022

Stoiko Ivanov said:
I sent an initial patch for this to the pve-devel list:
https://lists.proxmox.com/pipermail/pve-devel/2022-August/053803.html

if you can - please try it and provide feedback.

I'll try to update this thread once this patch or an improved version is available on our public test repositories

I changed the code in /usr/share/perl5/PVE/Auth/LDAP.pm

The result is the same, the users are still not being added to the CoreAdmins group.

LDAP: Users do not get synced in the group they belong to

Member

Member

Member

Proxmox Staff Member

Member

Member

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Proxmox Staff Member

Member

Member

Proxmox Staff Member

Member

Member