samba - Dec 2016 - Problem with keytab: "Client not found in Kerberos database"

I finally found it, thanks to a clue from 
https://wiki.archlinux.org/index.php/Active_Directory_Integration

This works:

kinit -k -t /etc/krb5.keytab 'WRN-RADTEST$'

These don't work:

kinit -k -t /etc/krb5.keytab
kinit -k -t /etc/krb5.keytab host/wrn-radtest.ad.example.net
kinit -k -t /etc/krb5.keytab host/wrn-radtest

That is: the keytab contains three different principals:

root at wrn-radtest:~# net ads keytab list
Vno  Type                                        Principal
   2  des-cbc-crc host/wrn-radtest.ad.example.net at AD.EXAMPLE.NET
   2  des-cbc-md5 host/wrn-radtest.ad.example.net at AD.EXAMPLE.NET
   2  aes128-cts-hmac-sha1-96 host/wrn-radtest.ad.example.net at AD.EXAMPLE.NET
   2  aes256-cts-hmac-sha1-96 host/wrn-radtest.ad.example.net at AD.EXAMPLE.NET
   2  arcfour-hmac-md5 host/wrn-radtest.ad.example.net at AD.EXAMPLE.NET
   2  des-cbc-crc host/wrn-radtest at AD.EXAMPLE.NET
   2  des-cbc-md5 host/wrn-radtest at AD.EXAMPLE.NET
   2  aes128-cts-hmac-sha1-96 host/wrn-radtest at AD.EXAMPLE.NET
   2  aes256-cts-hmac-sha1-96 host/wrn-radtest at AD.EXAMPLE.NET
   2  arcfour-hmac-md5 host/wrn-radtest at AD.EXAMPLE.NET
   2  des-cbc-crc WRN-RADTEST$@AD.EXAMPLE.NET
   2  des-cbc-md5 WRN-RADTEST$@AD.EXAMPLE.NET
   2  aes128-cts-hmac-sha1-96 WRN-RADTEST$@AD.EXAMPLE.NET
   2  aes256-cts-hmac-sha1-96 WRN-RADTEST$@AD.EXAMPLE.NET
   2  arcfour-hmac-md5 WRN-RADTEST$@AD.EXAMPLE.NET

I can get a TGT for any of them, and by default kinit chooses the 
first.  But the LDAP server won't talk to me unless I choose the 
'WRN-RADTEST$' principal.

Now I just need to work out how to get freeradius to choose the right 
principal - but at worst I should be able to make a new keytab which 
doesn't have the other two.

Regards,

Brian.

Rowland Perry wrote:
> >/imdap config AD : backend = rid /> >/ > /> How did you
'fix' this, on face value, there is nothing wrong with that line.

"imdap" is not "idmap"

(so now you understand why I missed it after staring at it so long :-)


 > When you join the domain with 'kerberos method = secrets and
keytab',
 > you should get a keytab created without having to manually create it.

Ah cool, yes that does happen now.

L.P.H. van Belle wrote:
> This is what i found, dont know if thats exact what your looking for.
>
> ( module )
> krb5 {
>         keytab = /etc/freeradius/keytab
>         service_principal = radius/radius.example.com
> }

I can't use rlm_krb5, because I plan to use PEAP+MSCHAP for wifi 
authentication. The krb5 module requires a cleartext password, but 
MSCHAP does not pass a cleartext password. (It is possible to use krb5 
authentication with TTLS+PAP or TTLS+GTC, both of which send a cleartext 
password)

However, I'm not actually at that point yet. First I'm configuring 
freeradius to do the LDAP query. To do this I'm setting environment 
variables:

KRB5_CLIENT_KTNAME=/etc/krb5.keytab
KRB5CCNAME=MEMORY:

Using KRB5_CLIENT_KTNAME means that the Kerberos library will 
automatically fetch and renew ticket when required. And I'm telling it 
to use the in-process MEMORY cache to hold those tickets.

Aside: there is a nasty failure mode if you don't do it like this. 
Suppose you type "kinit" to get a ticket, then start your radius
server.
Everything appears to work fine, since radius uses the ticket you 
generated. But then it stops working 12 hours later when the ticket 
expires :-(

(Incidentally, this is all stuff I have working with FreeIPA; I'm trying 
to port these working configs over to a Samba environment)

So, back to the situation I'm in, where /etc/krb5.keytab has three 
principals, but the first two don't work for authenticating the RADIUS 
server to the LDAP server to do LDAP queries.

POSSIBLE CAUSE: I found the following: 
http://serverfault.com/questions/682374/client-not-found-in-kerberos-database-while-getting-initial

/"Active Directory does not typically allow you to authenticate as a 
service principal (specifically, does not let it acquire a TGT via an 
AS_REQ); in theory, service principals are supposed to be for accepting 
user credentials, not for authenticating to your kerberos realm.//
//
//This is different from Unix KDCs, which typically do not distinguish 
between "service principals" and "user principals" by
default, allowing
either to authenticate via kinit"//
//
/This doesn't mention *host* principals as such, but it seems likely 
that host/foo at realm and service/foo at realm are both not allowed to 
authenticate to Active Directory.

And here: 
http://community.centrify.com/t5/Centrify-Express/Kerberos-Client-not-found-in-Kerberos-database/td-p/20591

This also says you must kinit as '<computername>$'


WORKAROUND: I couldn't get freeradius to select a principal to use for 
authentication, so instead I used ktutil to generate a keytab containing 
only the 'WRN-RADTEST$' principal.

rkt /etc/krb5.keytab
delent 1   # repeat this 10 times
wkt /etc/radius.keytab

and chown'd this file so the radius server can access it. This now 
works, yay! - freeradius can establish a connection to the LDAP server. 
However:


(1) Does Samba change the host kerberos key periodically?

If it does, I'll need to automate the updating of the radius keytab as 
well. Unfortunately ktutil is not well suited to this role, unless you 
are happy to type commands 'blind' to delete the first 10 entries (ugh)

(2) Can "net ads keytab create" be told to extract just a single named
principal? That would simplify things. But I can't see how to.

As usual... clues gratefully received.

Regards,

Brian.

On Tue, 20 Dec 2016 13:50:40 +0000
Brian Candler via samba <samba at lists.samba.org> wrote:
> Rowland Perry wrote:
> > >/imdap config AD : backend = rid /> >/ > /> How did
you 'fix'
> > >this, on face value, there is nothing wrong with that line.
> 
> 
> "imdap" is not "idmap"
> 
> (so now you understand why I missed it after staring at it so long :-)
Oh yes ;-)


> I can't use rlm_krb5, because I plan to use PEAP+MSCHAP for wifi 
> authentication. The krb5 module requires a cleartext password, but 
> MSCHAP does not pass a cleartext password. (It is possible to use
> krb5 authentication with TTLS+PAP or TTLS+GTC, both of which send a
> cleartext password)
You might want to read this:

https://www.samba.org/samba/history/samba-4.5.0.html

Rowland

( offtopic samba. ) 

About the "POSSIBLE CAUSE: I found the following.. " part. 
Thats exactly why my squid kerberos group didnt work. 

I manualy added this where it was needed. 

... 

A PROGRAM "login" to Windows Active Directory or Unix kdc as user
<SERVICE/<fqdn-hostname>@REALM >.
(! Beware SERVICE must match what your program needed ) 
Squid need HTTP/SPN
Zarafa needs http/SPN 

It requires Active Directory to have an attribute userPrincipalname set to 
< SERVICE/<fqdn-hostname>@REALM > for the associated acount. 
This is usaully done by using msktutil. 
But this is not done by samba-tools  

So you need to add this manualy. 


Greetz, 

Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Brian Candler
via
> samba
> Verzonden: dinsdag 20 december 2016 14:51
> Aan: samba
> Onderwerp: Re: [Samba] Problem with keytab: "Client not found in
Kerberos
> database"
> 
> Rowland Perry wrote:
> > >/imdap config AD : backend = rid /> >/ > /> How did
you 'fix' this, on
> face value, there is nothing wrong with that line.
> 
> 
> "imdap" is not "idmap"
> 
> (so now you understand why I missed it after staring at it so long :-)
> 
> 
>  > When you join the domain with 'kerberos method = secrets and
keytab',
>  > you should get a keytab created without having to manually create it.
> 
> Ah cool, yes that does happen now.
> 
> L.P.H. van Belle wrote:
> 
> > This is what i found, dont know if thats exact what your looking for.
> >
> > ( module )
> > krb5 {
> >         keytab = /etc/freeradius/keytab
> >         service_principal = radius/radius.example.com
> > }
> 
> 
> I can't use rlm_krb5, because I plan to use PEAP+MSCHAP for wifi
> authentication. The krb5 module requires a cleartext password, but
> MSCHAP does not pass a cleartext password. (It is possible to use krb5
> authentication with TTLS+PAP or TTLS+GTC, both of which send a cleartext
> password)
> 
> However, I'm not actually at that point yet. First I'm configuring
> freeradius to do the LDAP query. To do this I'm setting environment
> variables:
> 
> KRB5_CLIENT_KTNAME=/etc/krb5.keytab
> KRB5CCNAME=MEMORY:
> 
> Using KRB5_CLIENT_KTNAME means that the Kerberos library will
> automatically fetch and renew ticket when required. And I'm telling it
> to use the in-process MEMORY cache to hold those tickets.
> 
> Aside: there is a nasty failure mode if you don't do it like this.
> Suppose you type "kinit" to get a ticket, then start your radius
server.
> Everything appears to work fine, since radius uses the ticket you
> generated. But then it stops working 12 hours later when the ticket
> expires :-(
> 
> (Incidentally, this is all stuff I have working with FreeIPA; I'm
trying
> to port these working configs over to a Samba environment)
> 
> So, back to the situation I'm in, where /etc/krb5.keytab has three
> principals, but the first two don't work for authenticating the RADIUS
> server to the LDAP server to do LDAP queries.
> 
> POSSIBLE CAUSE: I found the following:
> http://serverfault.com/questions/682374/client-not-found-in-kerberos-
> database-while-getting-initial
> 
> /"Active Directory does not typically allow you to authenticate as a
> service principal (specifically, does not let it acquire a TGT via an
> AS_REQ); in theory, service principals are supposed to be for accepting
> user credentials, not for authenticating to your kerberos realm.//
> //
> //This is different from Unix KDCs, which typically do not distinguish
> between "service principals" and "user principals" by
default, allowing
> either to authenticate via kinit"//
> //
> /This doesn't mention *host* principals as such, but it seems likely
> that host/foo at realm and service/foo at realm are both not allowed to
> authenticate to Active Directory.
> 
> And here:
> http://community.centrify.com/t5/Centrify-Express/Kerberos-Client-not-
> found-in-Kerberos-database/td-p/20591
> 
> This also says you must kinit as '<computername>$'
> 
> 
> WORKAROUND: I couldn't get freeradius to select a principal to use for
> authentication, so instead I used ktutil to generate a keytab containing
> only the 'WRN-RADTEST$' principal.
> 
> rkt /etc/krb5.keytab
> delent 1   # repeat this 10 times
> wkt /etc/radius.keytab
> 
> and chown'd this file so the radius server can access it. This now
> works, yay! - freeradius can establish a connection to the LDAP server.
> However:
> 
> 
> (1) Does Samba change the host kerberos key periodically?
> 
> If it does, I'll need to automate the updating of the radius keytab as
> well. Unfortunately ktutil is not well suited to this role, unless you
> are happy to type commands 'blind' to delete the first 10 entries
(ugh)
> 
> (2) Can "net ads keytab create" be told to extract just a single
named
> principal? That would simplify things. But I can't see how to.
> 
> As usual... clues gratefully received.
> 
> Regards,
> 
> Brian.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Am 20.12.2016 um 14:50 schrieb Brian Candler via samba:
> (2) Can "net ads keytab create" be told to extract just a single
named
> principal? That would simplify things. But I can't see how to.
>
> As usual... clues gratefully received.
samba-tool domain exportkeytab [keytabfile] --principal=[SPN or UPN]

In your case

samba-tool domain exportkeytab /etc/krb5.keytab --principal=WRN-RADTEST$