User authentication with Active Directory: Realm join vs. SSSD?

[speck]

I'm reading through the documentation (https://pve.proxmox.com/pve-docs/chapter-pveum.html#user-realms-ad) about leveraging our existing AD domain for Proxmox. It looks like a fairly straightforward LDAP configuration, but it looks like it does have the downside that authentication & authorization would not be performed against the domain in real time; there is a requirement to sync from the realm to the config kept locally on the PVE cluster.

This is obviously doable, but it seems a downside to me that after adjusting a user account in AD, a separate step of synchronizing the PVE cluster to the realm would be required to reflect the changes.

So I started wondering: why not install SSSD and join the host to the domain, and continue to use the PAM stack? What am I overlooking?


-Thanks,

speck

 

[cheiss]

Hi,

but it looks like it does have the downside that authentication & authorization would not be performed against the domain in real time; there is a requirement to sync from the realm to the config kept locally on the PVE cluster.

Authentication is always done against the LDAP/AD server. The syncing only retrieves usernames, emails, person names, groups etc., such that you can then assign appropriate permissions to each user/group and thus have proper authorization in Proxmox VE itself.
When a user logs in, the authentication is still forwarded to the upstream LDAP/AD server.

This is obviously doable, but it seems a downside to me that after adjusting a user account in AD, a separate step of synchronizing the PVE cluster to the realm would be required to reflect the changes.

Depends on what you change and try to achieve. There are also realm sync jobs for automatically syncing user/group data at configurable intervals.

So I started wondering: why not install SSSD and join the host to the domain, and continue to use the PAM stack? What am I overlooking?

This is of course more complicated, but could be done if you e.g. want your users to have proper user accounts and thus have login shells on the nodes. It isn't supported as such in Proxmox VE, but as the PAM realm just forwards the authentication part to PAM, it's definitely possible.

 

[speck]

Thanks cheiss, for the input.

I'm glad to hear that the authentication data (passwords or MFA) is not synced or cached within Proxmox VE.

The main goal I suppose would be managing authorization by managing group membership on the AD side. Being able to add/remove users from a "Proxmox Admin" AD group, for example, to control who can log into either the web UI or CLI.

Not requiring a bind account might be a consideration, but a full domain join would create a machine account so I suppose that's up to a security auditor's opinion on what's preferred...

One consideration for the future might be how granular we would want to assign roles or permissions to users. For our use case with a small support team, a simple binary "are they an administrator or not" will probably be enough.

 

[cheiss]

The main goal I suppose would be managing authorization by managing group membership on the AD side. Being able to add/remove users from a "Proxmox Admin" AD group, for example, to control who can log into either the web UI or CLI.

That's definitely doable (and pretty much the way it's supposed to be used) - using the user and/or group filter you can filter results for the desired entities, using standard LDAP filter syntax.

And then having a realm sync job in an appropriate interval. Unfortunately there's not really any other way than polling/syncing in regular intervals with LDAP.

 

[speck]

Thanks again cheiss for the help!

I've gone ahead with my test cluster and done both: joined it to the AD domain using realmd for SSH/console and sudo access at the OS level, as well as configuring an LDAP authentication realm within Proxmox PVE for authorization. I'm slowly climbing the learning curve...

Not sure that this is the appropriate forum for suggestions, but here are some of my observations about the process:

1. I chose to configure an "LDAP" realm rather than "Active Directory" for one reason: the "Active Directory" doesn't seem to offer a Base DN option, which means that every AD group and user from the forest appears during a sync. I didn't need all of the builtin groups or computer accounts, etc. cluttering up the Proxmox PVE users and groups. I was able to reduce the clutter somewhat with a user filter to include only user accounts which are members of an OU, as well as excluding all disabled accounts.
2. It would be convenient for the flexibility to specify separate Base DNs for Users separately from Groups.
3. With the --sync_attributes option I was able to map the users' "Description" field to the "Comment" column; I do not see a similar option for use with groups? For now I'm just hiding the "Comment" column in the UI.
4. The tags to --sync_attributes are case-sensitive. I had to look at the perl code in /usr/share/perl5/PVE/Auth/LDAP.pm to figure out why it was complaining that "LastName" wasn't recognized as a valid attribute. Maybe consider changing this, or at least documenting it as such?
5. Would it be worth considering including a way to map the "Expires" and "Enabled" attributes when syncing from LDAP/AD? This isn't a large worry for me, as a user should be denied logon by the DC, but since those options are present and shown in the UI...
6. I notice that the --sslversion option available at the CLI isn't present in the GUI.

Configuring the realm sync job was a piece of cake in the GUI; 24 hours later it seems to be working fine.

In case it helps anyone finding this thread later, here's the command I used to create the LDAP realm against my Active Directory domain:

# Set HISTCONTROL to not add this command to the history file, since we're including a password at the commandline...
HISTCONTROL=ignorespace

# Execute the "realm add" command to create the LDAP authentication realm
# Values sanitized below; replace "DOMAIN.LOCAL" and bind account, etc. to fit
# User filter requires users to be located in AD subtree under AD_SITE and excludes disabled accounts from sync
# Note the leading space for the $HISTCONTROL option above...
  pveum realm add DOMAIN.LOCAL --type ldap --comment "DOMAIN.LOCAL" --default 1 --check-connection 1    \
    --mode="ldap+starttls"    \
    --server1="dc1.DOMAIN.LOCAL" --server2="dc2.DOMAIN.LOCAL" \
    --base_dn "OU=AD_SITE,DC=DOMAIN,DC=LOCAL"    \
    --bind_dn "CN=proxmox bind,OU=Service Accounts,OU=AD_SITE,DC=DOMAIN,DC=LOCAL"    \
    --filter "(&(MemberOf=CN=AD_SITE,CN=Users,DC=DOMAIN,DC=LOCAL)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"    \
    --user_attr "sAMAccountName" --user_classes "Person"    \
    --sync-defaults-options "remove-vanished=acl;entry;properties"    \
    --sync_attributes "firstname=givenname,lastname=sn,email=mail,comment=description" \
    --password "<BIND_PASSWORD>"

-Cheers,

speck