Is anyone familiar with using kerberos tickets from AD for linux clients?

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
AveryFreeman

AveryFreeman

consummate homelabber
Mar 17, 2017
425
57
28
43
Near Seattle
averyfreeman.com
Hey,

I recently started trying to authenticate my linux clients using ktpass on an AD-connected Windows client to generate a kerberos keytab for use in linux.

Here's the main guide I'm following: https://social.technet.microsoft.co...keytabs-to-integrate-non-windows-systems.aspx

It seems to work OK, but I'm noticing I have some unpredictable behavior when applying the keytab in Linux. I have two clients I'm trying to authenticate, one Debian Bullseye, one Ubuntu 20.04 LTS. Here's an example of my kerberos keytab generation (on AD-connected Windows server 2019):

Bash: 
ktpass -out debianclient.keytab -mapUser administrator@DOMAIN.COM -pass password -mapOp set +DumpSalt -crypto all -ptype KRB5_NT_PRINCIPAL -princ LDAP/debianclient.DOMAIN.COM@DOMAIN.COM
I can make this keytab changing nothing but the hostname for each of the two clients, and kinit will work on one client, but not the other.

Here's an eample:

Code: 
# on debianclient - works

[root@debianclient]~/ # klist -kte /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  33 12/31/1969 16:00:00 LDAP/debianclient.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)

[root@debianclient]~/ # kinit -Vkt /etc/krb5.keytab LDAP/debianclient.domain.com@DOMAIN.COM
Using default cache: persistent:0:0
Using principal: LDAP/debianclient.domain.com@DOMAIN.COM
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5

# on ubuntuclient - doesn't work

[root@ubuntuclient]~/ # klist -kte /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  34 12/31/1969 16:00:00 LDAP/ubuntuclient.DOMAIN.COM@DOMAIN.COM (aes256-cts-hmac-sha1-96)

[root@ubuntuclient]~/ # kinit -Vkt /etc/krb5.keytab LDAP/ubuntuclient.DOMAIN.COM@DOMAIN.COM

Using default cache: persistent:0:0
Using principal: LDAP/ubuntuclient.domain.com@DOMAIN.COM
Using keytab: /etc/krb5.keytab
kinit: Client 'LDAP/ubuntuclient.domain.com@DOMAIN.COM' not found in Kerberos database while getting initial credentials
This disparity is happening despite both the clients having the same packages installed and same following config files, with nothing different between the two hosts changed except for self-describing hostnames in those that require it.:

Code: 
# Packages:

dpkg --get-selections | egrep 'sssd|winbind|samba|krb5' | sed 's:install$::'

krb5-config
krb5-locales
krb5-user
libgssapi-krb5-2:amd64
libkrb5-26-heimdal:amd64
libkrb5-3:amd64
libkrb5support0:amd64
libnss-winbind:amd64
libpam-winbind:amd64
python3-samba
samba
samba-common
samba-common-bin
samba-dsdb-modules:amd64
samba-libs:amd64
samba-vfs-modules:amd64
sssd
sssd-ad
sssd-ad-common
sssd-common
sssd-ipa
sssd-krb5
sssd-krb5-common
sssd-ldap
sssd-proxy
sssd-tools
winbind


# .conf files

/etc/hosts
/etc/resolv.conf
/etc/nsswitch.conf
/etc/krb5.conf
/etc/samba/smb.conf
/usr/lib/realmd/realmd-defaults.conf
/usr/lib/realmd/realmd-distro.conf
/etc/security/pam_winbind.conf
Here's a diff of the package versions:

Code: 
# debianclient = left, ubuntuclient = right

]krb5-config     2.6+nmu1                                      | krb5-config     2.6ubuntu1
krb5-locales    1.18.3-4                                      | krb5-locales    1.17-6ubuntu4.1
krb5-user       1.18.3-4                                      | krb5-user       1.17-6ubuntu4.1
libgssapi-krb5-2:amd64  1.18.3-4                              | libgssapi-krb5-2:amd64  1.17-6ubuntu4.1
libkrb5-26-heimdal:amd64        7.7.0+dfsg-2                  | libkrb5-26-heimdal:amd64        7.7.0+dfsg-1ubuntu1
libkrb5-3:amd64 1.18.3-4                                      | libkrb5-3:amd64 1.17-6ubuntu4.1
libkrb5support0:amd64   1.18.3-4                              | libkrb5support0:amd64   1.17-6ubuntu4.1
libnss-winbind:amd64    2:4.13.5+dfsg-1                       | libnss-winbind:amd64    2:4.11.6+dfsg-0ubuntu1.6
libpam-winbind:amd64    2:4.13.5+dfsg-1                       | libpam-winbind:amd64    2:4.11.6+dfsg-0ubuntu1.6
python3-samba   2:4.13.5+dfsg-1                               | python3-samba   2:4.11.6+dfsg-0ubuntu1.6
samba   2:4.13.5+dfsg-1                                       | samba   2:4.11.6+dfsg-0ubuntu1.6
samba-common    2:4.13.5+dfsg-1                               | samba-common    2:4.11.6+dfsg-0ubuntu1.6
samba-common-bin        2:4.13.5+dfsg-1                       | samba-common-bin        2:4.11.6+dfsg-0ubuntu1.6
samba-dsdb-modules:amd64        2:4.13.5+dfsg-1               | samba-dsdb-modules:amd64        2:4.11.6+dfsg-0ubuntu1.6
samba-libs:amd64        2:4.13.5+dfsg-1                       | samba-libs:amd64        2:4.11.6+dfsg-0ubuntu1.6
samba-vfs-modules:amd64 2:4.13.5+dfsg-1                       | samba-vfs-modules:amd64 2:4.11.6+dfsg-0ubuntu1.6
sssd    2.4.1-2                                               | sssd    2.2.3-3ubuntu0.4
sssd-ad 2.4.1-2                                               | sssd-ad 2.2.3-3ubuntu0.4
sssd-ad-common  2.4.1-2                                       | sssd-ad-common  2.2.3-3ubuntu0.4
sssd-common     2.4.1-2                                       | sssd-common     2.2.3-3ubuntu0.4
sssd-ipa        2.4.1-2                                       | sssd-ipa        2.2.3-3ubuntu0.4
sssd-krb5       2.4.1-2                                       | sssd-krb5       2.2.3-3ubuntu0.4
sssd-krb5-common        2.4.1-2                               | sssd-krb5-common        2.2.3-3ubuntu0.4
sssd-ldap       2.4.1-2                                       | sssd-ldap       2.2.3-3ubuntu0.4
sssd-proxy      2.4.1-2                                       | sssd-proxy      2.2.3-3ubuntu0.4
sssd-tools      2.4.1-2                                       | sssd-tools      2.2.3-3ubuntu0.4
winbind 2:4.13.5+dfsg-1                                       | winbind 2:4.11.6+dfsg-0ubuntu1.6

I'm really hoping someone with more experience doing this can give me a hint as to why kinit will work on one host but not the other!

Thanks
 
Last edited:
C

casperghst42

Member
Sep 14, 2015
118
23
18
56
Not having looked at anything of this for some years (more than some years), I would start with your ldap.conf and your krb5.conf to see if there are any differences.
 
AveryFreeman

AveryFreeman

consummate homelabber
Mar 17, 2017
425
57
28
43
Near Seattle
averyfreeman.com
casperghst42 said:
Not having looked at anything of this for some years (more than some years), I would start with your ldap.conf and your krb5.conf to see if there are any differences.
Click to expand...
I have never touched ldap.conf for configuring anything re: samba/winbind/sssd before, very interesting. I will have to man.

Why would ldap have anything to do with kinit, though?
 
C

casperghst42

Member
Sep 14, 2015
118
23
18
56
AveryFreeman said:
I have never touched ldap.conf for configuring anything re: samba/winbind/sssd before, very interesting. I will have to man.

Why would ldap have anything to do with kinit, though?
Click to expand...
Sorry, you're right - it is a few years ago when I last looked at these things.

kinit -Vkt /etc/krb5.keytab LDAP/ubuntuclient.DOMAIN.COM@DOMAIN.COM

You're trying to use the LDAP spn which is what is failing.

If you can do a 'kinit <username>' then you should be good to go as that is what is needed for a normal login.

You then need to configure pam. (or maybe I am misunderstanding something).

Have you looked at this: AuthenticatingLinuxWithActiveDirectorySssd - Debian Wiki or this Kerberos - Community Help Wiki.
 
AveryFreeman

AveryFreeman

consummate homelabber
Mar 17, 2017
425
57
28
43
Near Seattle
averyfreeman.com
casperghst42 said:
Sorry, you're right - it is a few years ago when I last looked at these things.

kinit -Vkt /etc/krb5.keytab LDAP/ubuntuclient.DOMAIN.COM@DOMAIN.COM

You're trying to use the LDAP spn which is what is failing.

Have you looked at this: AuthenticatingLinuxWithActiveDirectorySssd - Debian Wiki or this Kerberos - Community Help Wiki.
Click to expand...
Well, I'm trying to auth the entire host, rather than just one user. But maybe I'm over complicating things

Here's the workflow:

Create krb5.keytab using ktpass on domain-connected Windows client, specifying service/FQDN@REALM - host/ and LDAP/ seem like good all-purpose services for interfacing with AD (e.g. if the linux client has ldap access, it can create other accounts, etc.)
Copy keytab to Linux /etc/
Make sure krb5.conf specifies /etc/krb5.keytab as FILE
kinit -Vkt /etc/krb5.keytab created on WIndows client, using service/FQDN@REALM
then realmd join -v -U user while keytab already initialized
Check all pertinent services to make sure they're happy (e.g. systemctl status sssd smbd nmbd winbind)

I've gotten this to work a couple times, but it seems inconsistent. There's so many moving pieces. My ubuntu box is actually working fine for auth + file sharing + file share access right now, but the debian client isn't (it was the other way around before).

Checking in on Ubuntu VM again, looks like domain auth still works fine after about a week, so that's encouraging

I've been following this and a bunch of other kerberos-specific stuff, maybe that's my problem: https://social.technet.microsoft.co...keytabs-to-integrate-non-windows-systems.aspx

BTW after realmd, the keytab files go from looking like this:

Code: 
# klist -kte /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  45 12/31/1969 16:00:00 host/debianclient.DOMAIN.COM@DOMAIN.COM (aes256-cts-hmac-sha1-96)
to something like this:

Code: 
# klist -kte /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  21 12/31/1969 16:00:00 LDAP/debianclient.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 debianclient$@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  45 03/18/2021 12:47:26 debianclient$@DOMAIN.COM (aes128-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 debianclient$@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 host/debianclient@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  45 03/18/2021 12:47:26 host/debianclient@DOMAIN.COM (aes128-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 host/debianclient@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 RestrictedKrbHost/debianclient@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  45 03/18/2021 12:47:26 RestrictedKrbHost/debianclient@DOMAIN.COM (aes128-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 RestrictedKrbHost/debianclient@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 HOST/debianclient.domain.com@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  45 03/18/2021 12:47:26 HOST/debianclient.domain.com@DOMAIN.COM (aes128-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 HOST/debianclient.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 TERMSRV/debianclient.domain.com@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  45 03/18/2021 12:47:26 TERMSRV/debianclient.domain.com@DOMAIN.COM (aes128-cts-hmac-sha1-96)
  45 03/18/2021 12:47:26 TERMSRV/debianclient.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
So it's definitely using the keytab file. I believe the keytab cache is something else (should probably look that up...)

And the query of the spn from Windows looks like this:

Code: 
C:\ setspn -l ubuntuclient

Registered ServicePrincipalNames for CN=ubuntuclient,CN=Computers,DC=domain,DC=com:
        host/ubuntuclient
        LDAP/ubuntuclient.domain.com
        RestrictedKrbHost/ubuntuclient
        RestrictedKrbHost/ubuntuclient.domain.com
        HOST/ubuntuclient.domain.com
The last one is my Ubuntu client, the one that appears to be working correctly for the moment....

I just wish I could figure out why one will allow the kinit service/FQDN@REALM sometimes and not others, then the other one won't, it just seems so odd... I'm guessing I must've done something different in regards to the ktpass generation, but there's just so damn much going on here...
 
AveryFreeman

AveryFreeman

consummate homelabber
Mar 17, 2017
425
57
28
43
Near Seattle
averyfreeman.com
More info:

OK, so I've made user keytabs and computer keytabs. Generally speaking, the user keytabs seem easiest to manage

I've been kind of trying to do a hybrid connection between winbind and sssd simultaneously, because sssd works pretty reliably for authentication, but winbind appears to be necessary for samba file shares ... so that's irritating

I'm sticking with just winbind for now, using some of the "older" tools likenet and adcli instead of realm, so I can get a better feeling for the internals, and with the hopes that if I get winbind working correctly I'll be able to authenticate with it and not need sssd (I know it's possible, in theory)...

If I make the keytab using -crypto all, it seems like if one crypto type isn't compatbile with a service in Linux, another one will be ...

here's an eg user keytab gen (KRB5_NT_PRINCINPAL = typically user account):

Code: 
ktpass -out ktab-user.keytab -mapuser administrator@DOMAIN.COM -pass userpassword -mapOp set
+DumpSalt -crypto all -ptype KRB5_NT_PRINCIPAL -princ LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM
Copy that to the linux client, and now can use net ads join -U administrator@DOMAIN.COM for a straight winbind connection, as long as parameters set in /etc/samba/smb.conf:

Code: 
# cat /etc/samba/smb.conf
[global]
        bind interfaces only = no
        winbind refresh tickets = yes
        # interfaces = 192.168.1.23/24 ens192
        log file = /var/log/samba/log.%m
        logging = file
        max log size = 1000
        obey pam restrictions = Yes
        pam password change = Yes
        panic action = /usr/share/samba/panic-action %d
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        server role = member server
        server string = %h server (Samba, Debian)
        template shell = /bin/bash
        idmap config domain.com : range = 10000-999999
        idmap config domain.com : backend = ad
        idmap config * : range = 3000-7999
        shadow: localtime = yes
        shadow: format = %m.%d.%Y-%H.%M.%S
        shadow: sort = desc
        # shadow: snapdir = .zfs/snapshot
        idmap config * : backend = tdb
        dedicated keytab file = /etc/krb5.keytab
        kerberos method = system keytab
        winbind use default domain = no
        winbind enum users = yes
        winbind enum groups = yes
        winbind offline logon = yes
        vfs objects = acl_xattr shadow_copy2
        map acl inherit = Yes
        store dos attributes = Yes
        template homedir = /home/%U@%D
        security = ADS

[homes]
        comment = Home Directories
        create mask = 0700
        directory mask = 0700
        valid users = %S
Join with net ads:

Code: 
# klist -kte /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  55 12/31/1969 16:00:00 LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM (DEPRECATED:des-cbc-crc)
  55 12/31/1969 16:00:00 LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM (DEPRECATED:des-cbc-md5)
  55 12/31/1969 16:00:00 LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM (DEPRECATED:arcfour-hmac)
  55 12/31/1969 16:00:00 LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
  55 12/31/1969 16:00:00 LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM (aes128-cts-hmac-sha1-96)

# kinit -Vkt /etc/krb5.keytab LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM

Using existing cache: persistent:0:krb_ccache_xN8W7a3
Using principal: LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5

# net ads join -U administrator@DOMAIN.COM

Enter administrator@DOMAIN.COM's password:
Using short domain name --DOMAIN
Joined 'DEBIANCLIENT' to dns domain 'domain.com'

kerberos_kinit_password DEBIANCLIENT$@DOMAINCOM failed: KDC has no support for encryption type
DNS update failed: kinit failed: KDC has no support for encryption type

root@DEBIANCLIENT:/home/avery/Projects/kerberos-tickets# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_xN8W7a3
Default principal: LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM

Valid starting Expires Service principal
03/23/2021 04:42:45 03/23/2021 14:42:45 krbtgt/DOMAIN.COM@DOMAIN.COM
renew until 03/30/2021 04:42:45

# klist -e
Ticket cache: KEYRING:persistent:0:krb_ccache_xN8W7a3
Default principal: LDAP/DEBIANCLIENT.domain.com@DOMAIN.COM

Valid starting Expires Service principal
03/23/2021 04:42:45 03/23/2021 14:42:45 krbtgt/DOMAIN.COM@DOMAIN.COM
renew until 03/30/2021 04:42:45, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Now I'm realizing there's an encryption disconnect between the domain controllers and the clients. Apparently they can make AES256-SHA1 keys, but they aren't set up to read them?

docs.microsoft.com

Kerberos Unsupported etype error - Windows Server

Describes how to resolve a configuration problem that prevents clients from authenticating when they attempt to access resources in a trusted domain.
docs.microsoft.com

But I found this awesome diagnostic tool that should help going forward:

Code: 
$ KRB5_TRACE=/dev/stdout KRB5_CONFIG=/etc/krb5.conf adcli join -K /etc/krb5.keytab -D domain.com -S 192.186.1.2 -v  --show-output
Tracing explained: Troubleshooting — MIT Kerberos Documentation

Tracing shown in action:

1683745 – Issue is that with arcfour-hmac as first encryption type in the config lines, adcli will pick arcfour-hmac to check which kind of salt should be used to encrypt the keys. But since arcfour-hmac does not use salts, all salt types will work and a wrong one

bugzilla.redhat.com bugzilla.redhat.com
 
Last edited:
RobstarUSA

RobstarUSA

Active Member
Sep 15, 2016
235
104
43
Did you get this working to your satisfaction? I've found using adjoin and sssd to talk to AD much easier. If you poke around (I think in the 20.04 or 20.10) ubuntu installer they have this option availale at installer. This is one of my side projects at work, and I've been using KRB tickets to log into my linux boxes to save password typing. It works great!
 
You must log in or register to reply here.
Top Bottom