New LDAP Sync feature - questions around "full" sync, and ETA?

victorhooi · May 4, 2020

Hi,

I saw on the pve-devel mailing list last month (April 2020) there is talk about some new LDAP sync functionality for users and groups:

https://pve.proxmox.com/pipermail/pve-devel/2020-March/042097.html
https://pve.proxmox.com/pipermail/pve-devel/2020-April/042938.html
https://pve.proxmox.com/pipermail/pve-devel/2020-April/043289.html

I currently use the Google Secure LDAP feature (https://support.google.com/a/answer/9048516?hl=en) to connect Proxmox to the users in my G Suite domain. (several thousand users).

However, I also need to manually create a matching Proxmox user in user.cfg as well.

It sounds like this functionality will do away with that, right? So I can just point Proxmox at a LDAP server, and it will pull users and groups directly from there, and write these out to user.cfg?

If so - this is amazing! =). Is there any idea of when this functionality will land in testing?

Secondly, I noticed the "full" mode (mentioned https://pve.proxmox.com/pipermail/pve-devel/2020-April/043289.html) does a two-way sync, and deletes users that aren't in the LDAP directory. What about local Linux users such as "root"? Will these no longer be able to login to Proxmox, if you use "full" mode?

Thanks,
Victor

dcsapak · May 4, 2020

victorhooi said:
It sounds like this functionality will do away with that, right? So I can just point Proxmox at a LDAP server, and it will pull users and groups directly from there, and write these out to user.cfg?

well currently the sync step ist still manually as in you have to call 'pveum sync <realm> [options]' manually (but this can be automated via e.g. a systemd-timer)

victorhooi said:
Is there any idea of when this functionality will land in testing?

the backend part is already on pvetest, the gui part will come a bit later (though you can already use it via cli/api)

victorhooi said:
Secondly, I noticed the "full" mode (mentioned https://pve.proxmox.com/pipermail/pve-devel/2020-April/043289.html) does a two-way sync, and deletes users that aren't in the LDAP directory. What about local Linux users such as "root"? Will these no longer be able to login to Proxmox, if you use "full" mode?

no this is not a two-way sync, as the docs mentioned it uses the ldap as source of truth (instead of the user.cfg) here a short example:

current user.cfg:

Code:

...
foo@bar:1:0:::foo@bar.com::
foo2@bar:1:0:::foo2@bar.com::
foo3@bar:1:0:::::
...

now you get via ldap:

Code:

name: foo, email: foo_new@bar.com
name: foo3, email: foo3@bar.com

(note the missing foo2)

without full, the result is

Code:

foo@bar:1:0:::foo@bar.com::
foo2@bar:1:0:::foo2@bar.com::
foo3@bar:1:0:::foo3@bar.com::

(it keeps the users and the configured mail)

with full, the result is

Code:

foo@bar:1:0:::foo_new@bar.com::
foo3@bar:1:0:::foo3@bar.com::

foo2 is deleted from user.cfg, and foo got the '_new' mail adress from ldap

our sync will never modify the ldap server, just sync down from it (so the second part of the question does not really make sense)

edit: i believe i just understood the last question... the sync is always realm specific, so the pam and pve realm (and other ldap realms) will not be touched, so no root can still login (as can users from other realms)

victorhooi · May 6, 2020

Hi Dominik

Thanks for the detailed info!

I just did an apt update and apt dist-upgrade on my cluster - I did see there was an update for the "libpve-access-control" package from 6.0-6 to 6.0-7, which is the version that has the new sync CLI.

It took me a while to realise the command is "pveum realm sync" (not pveum sync), haha.

It was a bit confusing at first - as "full" and "purge" are required arguments.

Code:

# pveum realm sync "example.io" --dry-run --scope both
400 Parameter verification failed.
full: Not passed as parameter and not defined in realm default sync options.
pveum realm sync <realm> [OPTIONS]

However, I was finally able it to run like so:

Code:

# pveum realm sync "example.io" --full --purge --scope both
starting sync for realm example.io
got data from server, updating users and groups
syncing users
full sync, deleting outdated existing users first
syncing groups
full sync, deleting outdated existing groups first
successfully updated users and groups configuration

However - no actual users were synced....is there a way to diagnose why it's not picking up any users?

This is the contents of my /etc/pve/domains.cfg:

Code:

# cat domains.cfg
pam: pam
        comment Linux PAM standard authentication

ldap: example.io
        base_dn dc=example,dc=io
        server1 ldap.google.com
        user_attr uid
        cert /etc/pve/priv/Google_2022_05_22_3494.crt
        certkey /etc/pve/priv/Google_2022_05_22_3494.key
        port 636
        secure 1
        verify 1

pve: pve
        comment Proxmox VE authentication server

Second - my question around sync was more around local users (e.g. local Linux users). For example, on a new fresh cluster, my /etc/pve/user.cfg contains:

Code:

user:root@pam:1:0:::victorhooi@example.com::

Sorry if this is obvious - bu I confirm that any local users (e.g. root, or others) will be completely ignored when I run "pveum realm sync"?

Thanks,
Victor

dcsapak · May 6, 2020

victorhooi said:
However - no actual users were synced....is there a way to diagnose why it's not picking up any users?

check the other ldap paramters (pveum help realm modify) and their default values
maybe the default user/group classes are not correct, or the base/group_dn ?

dcsapak · May 6, 2020

victorhooi said:
Sorry if this is obvious - bu I confirm that any local users (e.g. root, or others) will be completely ignored when I run "pveum realm sync"?

yes, the sync will only touch the users of that specific realm, no local users and no users of other realms

victorhooi · May 6, 2020

My domain.cfg config should be in the above post, for reference.

As far as I'm aware - it should be correct, as existing LDAP users are able to login successfully to Proxmox via the LDAP realm.

Or are there perhaps additional attributes needed for the new Proxmox sync feature to work?

I found the schema for the G Suite SecureLDAP feature.

For users it says:

Person
A user in the domain. People appear under the organizational units that they belong to:

objectClass: top, person, organizationalPerson, inetOrgPerson, posixAccount

uid: The user’s username. The username portion of their email address.

googleUid: The same as the uid. This exists to unambiguously distinguish it from the posixUid.

posixUid: The user’s username or, if it is set, the user’s POSIX username.

cn: The “common name”. This contains two values: the user’s username and the user’s display name.

...<truncated>...

And for groups:

Group

objectClass: top, groupOfNames, posixGroup

cn: The group’s domain-unique name.

displayName: The group’s human-readable display name.

description: A longer human-readable description of the group.

gidNumber: The POSIX GID number for the group. This is a stable unique ID, but the group cannot be efficiently looked up by it

...<truncated>...

Is there something else I might have missed?

Could the G Suite OU (Organisational Unit) hierarchy have something to do with it? But then why do those users (either in the root OU, or in child OUs) work fine for Proxmox LDAP login?

dcsapak · May 6, 2020

victorhooi said:
As far as I'm aware - it should be correct, as existing LDAP users are able to login successfully to Proxmox via the LDAP realm.

Or are there perhaps additional attributes needed for the new Proxmox sync feature to work?

the thing is this: for login we just check if the user can bind to the ldap server, but for syncing we actually need to retrieve the entries from the ldap
and as i can see from your domain.cfg you did not specify a bind_dn and password so does the ldap server allow an anonymous bind?
if not, you have to give a user which can read from the ldap

victorhooi · May 6, 2020

Got it - I'll have to check about the anonymous bind thing.

I do know that running the ldapsearch command from a Linux box like so works - just using the certificate files, and no credentials:

Code:

$ LDAPTLS_REQCERT=allow LDAPTLS_CERT=Google_2022_05_22_3494.crt LDAPTLS_KEY=Google_2022_05_22_3494.key ldapsearch -H ldaps://ldap.google.com:636 -b dc=example,dc=io '(uid=victorhooi)'
SASL/EXTERNAL authentication started
SASL username: st=California,c=US,ou=GSuite,cn=LDAP Client,l=Mountain View,o=Google Inc.
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=io> with scope subtree
# filter: (uid=victorhooi)
# requesting: ALL
#

# victorhooi, Users, example.io
dn: uid=victorhooi,ou=Users,dc=example,dc=io
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: victorhooi
googleUid: victorhooi
posixUid: victorhooi
cn: victorhooi
cn: Victor Hooi
sn: Hooi
displayName: Victor Hooi
givenName: Victor
mail: victorhooi@example.io
memberOf: cn=chat-eng,ou=Groups,dc=example,dc=io
memberOf: cn=cloud-pso,ou=Groups,dc=example,dc=io
memberOf: cn=drive-eng,ou=Groups,dc=example,dc=io
memberOf: cn=drivefs-offshore-qa,ou=Groups,dc=example,dc=io
memberOf: cn=gsuite-professors,ou=Groups,dc=example,dc=io
memberOf: cn=gsuite-tses,ou=Groups,dc=example,dc=io
memberOf: cn=meet-eng,ou=Groups,dc=example,dc=io
memberOf: cn=vendors,ou=Groups,dc=example,dc=io
uidNumber: 950057616
gidNumber: 950057616
homeDirectory: /home/victorhooi
loginShell: /bin/bash
gecos:

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

However, you're saying that then Proxmox LDAP sync uses perhaps a different type of query, to dump everything?

Do you know what the equivalent ldapsearch command might be, so I can try it out please?

victorhooi · May 7, 2020

I also checked the audit logs for the G Suite SecureLDAP service - these are the events associated with my running:

Code:

# pveum realm sync "example.io" --dry-run --full --purge --scope both

In this case, the dry-run didn't return any users, and proposed deleting all the users I'd manually created.

From what I can tell in the screenshot - the bind itself was successful. Do you agree?

Could it be a schema issue?

If there's a manual ldapsearch command I can run, that should return the users and emulates what Proxmox does during a sync, I am happy to run that as well to compare.

Thanks,
Victor

dcsapak · May 7, 2020

victorhooi said:
In this case, the dry-run didn't return any users, and proposed deleting all the users I'd manually created.

yes thats what the --full parameter does

victorhooi said:
From what I can tell in the screenshot - the bind itself was successful. Do you agree?

yes seems so, but a successful bind does not mean the 'anonymous bind' user has access to the entries

victorhooi said:
If there's a manual ldapsearch command I can run, that should return the users and emulates what Proxmox does during a sync, I am happy to run that as well to compare.

you can see the exact filter we use in your audit log, basically objectclass is one of the defaults and at least one attribute must be set (e.g. uid) the rest of the filtering/matching
happens in perl then

liszca · May 8, 2020

Somehow users don't populate. Not sure if the syntax for group_filter is correct, but this one works with ldapsearch.

my domains.cfg

ldap: ldap
base_dn ou=people,dc=example
server1 ldap2.example
user_attr uid
bind_dn uid=ldap.read,ou=services,dc=example
default 1
filter (&(objectclass=person)(memberof=cn=linux,ou=groups,dc=example))
group_classes groupOfNames
group_filter (&(objectclass=groupOfNames)(cn=linux))
group_name_attr cn
port 636
secure 1
sync-defaults-options full=1,purge=1,scope=both
sync_attributes email=mail
user_classes person
verify 0

victorhooi · May 8, 2020

OK - I've confirmed that using an anonymous bind does return a list of users.

For example, here is the ldapsearch command - this successfully returns a list of all users in the G Suite domain.

Code:

LDAPTLS_REQCERT=allow LDAPTLS_CERT=Google_2022_05_22_3494.crt LDAPTLS_KEY=Google_2022_05_22_3494.key ldapsearch -H ldaps://ldap.google.com:636 -b dc=example,dc=io

If we want to do an authenticated bind - here is one using the user "victorhooi":

Code:

LDAPTLS_REQCERT=allow LDAPTLS_CERT=Google_2022_05_22_3494.crt LDAPTLS_KEY=Google_2022_05_22_3494.key ldapsearch -H ldaps://ldap.google.com:636 -b dc=example,dc=io -D uid=victorhooi,ou=Users,dc=example,dc=io -w <password>

For Proxmox, I was able to achieve the same using this domains.cfg:

Code:

pam: pam
        comment Linux PAM standard authentication

ldap: example.io
        base_dn dc=example,dc=io
       # bind_dn uid=victorhooi,ou=Users,dc=example,dc=io
        server1 ldap.google.com
        user_attr uid
        cert /etc/pve/priv/Google_2022_05_22_3494.crt
        certkey /etc/pve/priv/Google_2022_05_22_3494.key
        port 636
        secure 1
        verify 1

pve: pve
        comment Proxmox VE authentication server

And then I put my G Suite user's password in:

Code:

/etv/pve/priv/ldap/example.io.pw

After this, I can run pveum realm sync, and it does pull the users as expected.

I am curious why the anonymous bind doesn't work though - when the ldapsearch command using the anonymous bind above does pull users - but we seem to be making some progress =).

Where should we document all this behaviour?

victorhooi · May 11, 2020

Hi Dominik,

So I checked with the SecureLDAP team - they confirmed that querying the list of users should be possible using just the certificate files. (They referred to it as a service bind, not sure if this is the official term).

This correlates with what I saw with using ldapsearch as well - where the below command will return the required list of users.

Code:

LDAPTLS_REQCERT=allow LDAPTLS_CERT=Google_2022_05_22_3494.crt LDAPTLS_KEY=Google_2022_05_22_3494.key ldapsearch -H ldaps://ldap.google.com:636 -b dc=example,dc=io

(Btw, I emailed you a set of test credentials separately, so you can likely test this as well - let me know if it doesn't work)

However, from my other issue - if I use bind_dn in /etc/pve/domains.cfg, it breaks the normal Proxmox LDAP flow.

Is there some way of finding out why the pveum realm sync command does not work with just a certificate file, as per above?

dcsapak · May 12, 2020

victorhooi said:
Is there some way of finding out why the pveum realm sync command does not work with just a certificate file, as per above?

same reason as the other issue, because if no bind_dn is given a anonymous bind is done... so after the patch from the other issue this should be solved too

liszca · May 12, 2020

You can try to add the CA Certificate to your Proxmox Host:

Assuming the CA Certificate is allready copied from host ldap1.example.com to proxmox.example.com.

mkdir /usr/local/share/ca-certificates/extra
scp root@ldap1.example.com:/opt/improvisedCA/certs/cacert.pem root@proxmox.example.com:/usr/local/share/ca-certificates/extra/cacert.crt

Add Certificate …

update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

EDIT:
If neccessary you can figure out which the CA certificate is by running the comman:
openssl x509 -in /opt/improvisedCA/certs/cacert.pem -text -noout

Somewhere in the output you should find "CA:TRUE", then thats what you need.

victorhooi · Jun 9, 2020

I can verify this works querying against G Suite Secure LDAP:

Code:

root@angusmtv-vm01:/etc/pve# pveum realm sync "example.io" --dry-run --full --purge --scope both
(dry test run) starting sync for realm example.io
skipping anonymous bind with clientcert
skipping anonymous bind with clientcert
got data from server, updating users and groups
syncing users
full sync, deleting outdated existing users first
added user 'aalbelda@example.io'
added user 'aangelrodrigo@example.io'
...
added user 'zubiar@example.io'
syncing groups
full sync, deleting outdated existing groups first
added group 'foo-example.io'
added group 'bar-example.io'
added group 'blergh-example.io'

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

Search

Search

New LDAP Sync feature - questions around "full" sync, and ETA?

victorhooi

Well-Known Member

dcsapak

Proxmox Staff Member

victorhooi

Well-Known Member

dcsapak

Proxmox Staff Member

dcsapak

Proxmox Staff Member

victorhooi

Well-Known Member

dcsapak

Proxmox Staff Member

victorhooi

Well-Known Member

victorhooi

Well-Known Member

dcsapak

Proxmox Staff Member

liszca

Active Member

victorhooi

Well-Known Member

victorhooi

Well-Known Member

dcsapak

Proxmox Staff Member

liszca

Active Member

victorhooi

Well-Known Member