On Wed, 2019-07-31 at 09:26 +0200, Jakub Hrozek wrote:
On Tue, Jul 30, 2019 at 06:42:06PM +0200, Christian Lamparter wrote:
> On Fri, 2019-07-26 at 14:08 +0200, Jakub Hrozek wrote:
> > On Fri, Jul 26, 2019 at 12:50:16PM +0200, Christian Lamparter wrote:
> > > 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..
>
> Ok, thanks. I got it working. what I did was to patch (see below, it was
> for 1.16.3. But yeah I'll stick around since this has limitations) the
> sdap_auth_send by adding another state parameter that can overwrite
> sasl_mech logic and instruct the code to instead use the simple ldap bind
> with a ldap_default_bind_dn and ldap_default_authtok for the id lookups.
> (sort of like the binddn/bindpw that nslcd has for (all) lookups).
>
> (The ldap_sasl_authid did OK, but on reboot it broke. From what I can tell,
> it has to do with Debian decision to make /tmp a ramfs and some secrets
> get are stored there.)
Hmm, strange. As long as ldap_sasl_authid corresponds with a principal
in the keytab, this should work. There should not be any secrets stored
in /tmp afaik..
No luck with figuring this out. It seems to me (by looking at Windows as
well) that the ticket lifetime are extremly short. Is there a better way
to listen to the LDAP + Kerberos Messages other than adding printf & friends
everywhere? (since this is integrated into debian, I have to rebuild the whole
package each time, so debugging take a long time). Wireshark isn't of much
use since everything is encrypted. But at least, for the time being the
ldap_authtok_password overwrite works well.
> Anyway onwards!
>
> I can finally use login and friends with a twist. Just after the bash
> banner there's now a "Invalid user name" (I assume it has something
> to do with the "(a)domain.dc" in the user login, as well as the borked
> full user name (it's a guid instead of a name). But ls -al and id,
> getent passwd are all working. As well as the groups)
Ok, I figured this out. This was coming from the pmvarrun (libpam-mount).
And indeed it complains about the "@" in the valid_username() function.
So, while not ideal, the sssd.conf option
use_fully_qualified_names = False
removes this thorn.
Cheers,
Christian Lamparter