Hello Folks,
I'm currently setting up sssd (Debian 1.16.3) on Debian Buster 10.0 and I ran into a problem that I was able to trace down to the domain permission/security settings that placed the users into a special OU that machine accounts can't read.
First a bit of background: Currently, there's a way to use winbind + friends in order to join and auth users on the domain. But due to limitations (unreliable no home directories, gid/uid mapping issues, etc.), I want to give sssd a try and I tested this with both of the current Debian sssd version 1.16.3 and 2.2.0-4 (from unstable / sid / rolling release).
I successfully used the "realm" utility to discover and setup the sssd.conf === # realm discover -v DOMAIN (named changed) * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain domain type: kerberos realm-name: DOMAIN domain-name: domain configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin
# realm join -v -U me@DOMAIN domain * Resolving: _ldap._tcp.domain * Performing LDAP DSE lookup on: 1x.y.z.1 * Performing LDAP DSE lookup on: 1z.a.b.c * Performing LDAP DSE lookup on: 1d.e.f.g * Successfully discovered: domain Password for me@DOMAIN: ******* * Unconditionally checking packages * Resolving required packages [...] * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for COMPUTER * Set computer password * Retrieved kvno '14' for computer account in directory: ... * Modifying computer account: userAccountControl * Modifying computer account: operatingSystemVersion, operatingSystemServicePack * Modifying computer account: userPrincipalName * Cleared old entries from keytab: FILE:/etc/krb5.keytab * Discovered which keytab salt to use * Added the entries to the keytab: ... * /usr/sbin/update-rc.d sssd enable * /usr/sbin/service sssd restart * Successfully enrolled machine in realm ===
/etc/sssd/sssd.conf
[sssd] domains = domain config_file_version = 2 services = nss, pam, ifp # added ifp
[domain/domain] ad_domain = domain krb5_realm = DOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad ===
klist shows a valid ticket and everything seemed to be working.
But when I was trying to login (yes, I made sure that my time is synced and I made sure /etc/nssswitch.conf was correct) with my "me@domain" login it never worked. I tried also id me@domain and sssctl (had to add ifp, seems like realm doesn't add) but it wasn't working for my login.
After trying a lot of different combinations with different id, auth_providers and ldap I discovered that the AD Server is setup in such a way (probably due to DSVGO) that the Domain-PC Accounts are not allowed to read from the OU where all the staff users are placed. And indeed, when I copied the exact search query from the sssd_domain log with debug-level 7 and instructed ldapsearch to use GSSAPI with the Domain-PC ticket I always got a "not found". However, when I used simple bind with "me@domain" + password auth I got the request worked.
So, I wonder if it is possible to extend sssd in such a way that id lookups could be performed with the provided either a provided user secret instead of the machine secret?
Regards, Christian
sssd-users@lists.fedorahosted.org