[Samba] Joining Samba4 to Win 2008 AD domain breaks other kerberos functions

Gaiseric Vandal via samba

unread,

Mar 9, 2017, 5:50:03 PM3/9/17

to

I have a Windows 2008 domain (one Win 2008 DC, one Win 2012 R2 DC.)

I am trying to join a Solaris 11 machine to the domain for both Samba
and other services. For "unix" logins and ssh, Solaris 11 is configured
to use LDAP for user and group lookup and kerberos for authentication.

The "kclient -T ms_ad" command joins the Solaris machine to the AD
domain. It even creates the /etc/krb5/krb5.keytab file with several
service principal entries. (I pasted this at the bottom of this
e-mail.) This allows me to ssh in to the machine using my kerberos
password.

When I run "net ads join -S domaincontroller -U Administration" , the
samba join appears to work. However, I can no longer ssh in .

The log files shows

sshd[12225]: [ID 537602 auth.error] PAM-KRB5 (auth):
krb5_verify_init_creds failed: Key version number for principal in key
table is incorrect

I ran kvno prior to "net join" to see if I could find any changes on any
of the principals. I did not find any. However the "pwdLastSet"
attribute was updated (which means, not surprisingly, that the samba
"net ads join" changed machine's password when joining. I also
notice that the "msDS-SupportedEncryptionTypes" attribute is reset to 31
(i.e all encryption types.) I had change it to 28 (to exclude DES)

I tried setting "kerberos method = secrets and keytab" in smb.conf, but
did not help. I would think solution might be to create a new
krb5.keytab file on the AD server that has a single principal that can
provide authentication for both unix logins and samba. The kutil
command in Windows makes it pretty much impossible to create a
krb5.keytab file with multiple service principals.

What service principal is Samba using ? Assuming my machine is
"client1" in the realm "MYREALM" I would expect the principal to be
"CLIENT1$@MYREALM."

If I set "kerberos method = keytab" while samba try to create a keytab ?

I appreciate any advice

Thanks

root@client1:/etc/krb5# klist -ke

Keytab name: FILE:/etc/krb5/krb5.keytab

KVNO Principal

----
--------------------------------------------------------------------------

2 host/client1.my...@MYREALM.COM (AES-256 CTS mode
with 96-bit SHA-1 HMAC)

2 host/client1.my...@MYREALM.COM (AES-128 CTS mode
with 96-bit SHA-1 HMAC)

2 host/client1.my...@MYREALM.COM (ArcFour with HMAC/md5)

2 host/client1.my...@MYREALM.COM (DES cbc mode with
RSA-MD5)

2 nfs/client1.my...@MYREALM.COM (AES-256 CTS mode
with 96-bit SHA-1 HMAC)

2 nfs/client1.my...@MYREALM.COM (AES-128 CTS mode
with 96-bit SHA-1 HMAC)

2 nfs/client1.my...@MYREALM.COM (ArcFour with HMAC/md5)

2 nfs/client1.my...@MYREALM.COM (DES cbc mode with
RSA-MD5)

2 HTTP/client1.my...@MYREALM.COM (AES-256 CTS mode
with 96-bit SHA-1 HMAC)

2 HTTP/client1.my...@MYREALM.COM (AES-128 CTS mode
with 96-bit SHA-1 HMAC)

2 HTTP/client1.my...@MYREALM.COM (ArcFour with HMAC/md5)

2 HTTP/client1.my...@MYREALM.COM (DES cbc mode with
RSA-MD5)

2 root/client1.my...@MYREALM.COM (AES-256 CTS mode
with 96-bit SHA-1 HMAC)

2 root/client1.my...@MYREALM.COM (AES-128 CTS mode
with 96-bit SHA-1 HMAC)

2 root/client1.my...@MYREALM.COM (ArcFour with HMAC/md5)

2 root/client1.my...@MYREALM.COM (DES cbc mode with
RSA-MD5)

2 cifs/client1.my...@MYREALM.COM (AES-256 CTS mode
with 96-bit SHA-1 HMAC)

2 cifs/client1.my...@MYREALM.COM (AES-128 CTS mode
with 96-bit SHA-1 HMAC)

2 cifs/client1.my...@MYREALM.COM (ArcFour with HMAC/md5)

2 cifs/client1.my...@MYREALM.COM (DES cbc mode with
RSA-MD5)

2 CLIENT1$@MYREALM.COM (AES-256 CTS mode with 96-bit SHA-1
HMAC)

2 CLIENT1$@MYREALM.COM (AES-128 CTS mode with 96-bit SHA-1
HMAC)

2 CLIENT1$@MYREALM.COM (ArcFour with HMAC/md5)

2 CLIENT1$@MYREALM.COM (DES cbc mode with RSA-MD5)

2 host/CLI...@MYREALM.COM (AES-256 CTS mode with 96-bit
SHA-1 HMAC)

2 host/CLI...@MYREALM.COM (AES-128 CTS mode with 96-bit
SHA-1 HMAC)

2 host/CLI...@MYREALM.COM (ArcFour with HMAC/md5)

2 host/CLI...@MYREALM.COM (DES cbc mode with RSA-MD5)

2 cifs/CLI...@MYREALM.COM (AES-256 CTS mode with 96-bit
SHA-1 HMAC)

2 cifs/CLI...@MYREALM.COM (AES-128 CTS mode with 96-bit
SHA-1 HMAC)

2 cifs/CLI...@MYREALM.COM (ArcFour with HMAC/md5)

2 cifs/CLI...@MYREALM.COM (DES cbc mode with RSA-MD5)

root@client1:/etc/krb5#

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Gaiseric Vandal via samba

unread,

Mar 16, 2017, 2:50:02 PM3/16/17

to

Samba expects the keytab file as /etc/krb5.keytab.

Solaris 11 looks for a keytab file in /etc/krb5/krb5.keytab

When samba joins the domain it (probably) updates the machine password
and then updates its krb5.keytab file. When connecting via ssh,
the system would use a keytab file that had the wrong kvno and probably
the wrong password key.

The following symlink command fixed ssh logins

ln -s /etc/krb5.keytab /etc/krb5/krb5.keytab

Rowland Penny via samba

unread,

Mar 16, 2017, 3:10:04 PM3/16/17

to

On Thu, 16 Mar 2017 14:48:01 -0400
Gaiseric Vandal via samba <sa...@lists.samba.org> wrote:

> Samba expects the keytab file as /etc/krb5.keytab.
>
> Solaris 11 looks for a keytab file in /etc/krb5/krb5.keytab
>
> When samba joins the domain it (probably) updates the machine
> password and then updates its krb5.keytab file. When connecting
> via ssh, the system would use a keytab file that had the wrong kvno
> and probably the wrong password key.
>
>
> The following symlink command fixed ssh logins
>
> ln -s /etc/krb5.keytab /etc/krb5/krb5.keytab
>

Did you try:

kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5/krb5.keytab

Rowland

Gaiseric Vandal via samba

unread,

Mar 21, 2017, 9:10:03 AM3/21/17

to

On 03/16/17 15:01, Rowland Penny via samba wrote:
> On Thu, 16 Mar 2017 14:48:01 -0400
> Gaiseric Vandal via samba <sa...@lists.samba.org> wrote:
>
>> Samba expects the keytab file as /etc/krb5.keytab.
>>
>> Solaris 11 looks for a keytab file in /etc/krb5/krb5.keytab
>>
>> When samba joins the domain it (probably) updates the machine
>> password and then updates its krb5.keytab file. When connecting
>> via ssh, the system would use a keytab file that had the wrong kvno
>> and probably the wrong password key.
>>
>>
>> The following symlink command fixed ssh logins
>>
>> ln -s /etc/krb5.keytab /etc/krb5/krb5.keytab
>>
> Did you try:
>
> kerberos method = dedicated keytab
> dedicated keytab file = /etc/krb5/krb5.keytab
>
> Rowland
>

I did. It seemed to be ignored. When I join samba to a domain, I
don't know if it will update an existing keytab file or overwrite
it. The symlink seemed an easy workaround.

Rowland Penny via samba

unread,

Mar 21, 2017, 9:30:03 AM3/21/17

to

On Tue, 21 Mar 2017 08:57:22 -0400
Gaiseric Vandal via samba <sa...@lists.samba.org> wrote:

> > Did you try:
> >
> > kerberos method = dedicated keytab
> > dedicated keytab file = /etc/krb5/krb5.keytab
> >
> > Rowland
> >
>
> I did. It seemed to be ignored. When I join samba to a domain, I
> don't know if it will update an existing keytab file or overwrite
> it. The symlink seemed an easy workaround.
>
>

I usually delete the keytab before the join, otherwise the join seems
to hang, but this is on Linux. Perhaps on Solaris it does ignore an
existing keytab ?

Rowland