On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote:
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?
Sorry, not right now. The AD provider presumes that a keytab is used.
But there's nothing saying that the keytab must contain a machine
account principal. I guess you could create a keytab for some user, even
the one you used for the simple bind authentication and then instruct
sssd with the help of ldap_sasl_authid to use your custom principal (by
default sssd tries to search for principal based on the host name).
btw as a coincidence, I was looking into extending the IPA provider (which
has pretty much the same issues as the AD provider) so that a client
side certificate could be used. So in future this might also be
possible, but not right now..