On Thu, Apr 19, 2018 at 3:12 AM, Sumit Bose <sbose(a)redhat.com> wrote:
Unfortunately there is a special behavior of the AD provider which
is not documented in the man page which would use
MYCLIENT$(a)EXAMPLE.ORG as default, see below ...
OK…
>
> However, this is ambiguous. Does this mean:
>
> host/shorthostname@REALM
>
> …or does it mean:
>
> host/fqdn@REALM
Whatever you have written in userPrincipalName. With AD you can only get
a TGT for the principal in userPrincipalName or if this is not set for
sAMAccountName(a)AD.REALM (MYCLIENT$(a)EXAMPLE.ORG in the example above).
And this is what is needed to authenticate against Active Directory.
Ah; now this makes more sense.
This is almost certainly what was tripping us up. We were so focused
on getting the "host/fqdn" entries in the exported keytab correct,
because according to the sssd documentation, that's what sssd needed
to authenticate to AD. But the documentation did not reflect what
sssd was actually doing.
We'll make sure that "kinit -k 'MYCLIENT$'" is working with the
exported keytab. I'm very confident if that works, then sssd will
work.
As an aside, though…
let's circle back to the beginning, joining the AD domain.
Was my assumption correct that you used the --user-principal of adcli?
If yes, is there a reason or were you just trying different options to
make SSSD work?
Well, we use "net ads join", not adcli, becaues adcli wasn't available
way back when we first started our Linux hosts to AD (5+ years ago!).
But yes, you are correct. This is how we join our Linux hosts to AD:
$ net -d 1 -k ads join createcomputer=Servers/Linux
createupn=host/${HOSTNAME}(a)EXAMPLE.ORG
This produces this /etc/krb5.keytab file:
$ klist -k -e
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-crc)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/MYCLIENT(a)EXAMPLE.ORG (arcfour-hmac)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-crc)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-md5)
2 MYCLIENT$(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (arcfour-hmac)
And in AD, the computer object has a userPrincipalName attribute:
sAMAccountName: MYCLIENT$
dNSHostName:
myclient.example.org
userPrincipalName: host/myclient.example.org(a)EXAMPLE.ORG
servicePrincipalName:
HOST/myclient.example.org
servicePrincipalName: HOST/MYCLIENT
The presence of the host/myclient.example.org(a)EXAMPLE.ORG
userPrincipalName permits "kinit -k" to work without specifying a
principal, because "kinit -k" defaults to "host/fqdn", and
host/myclient.example.org is a valid principal because of the
userPrincipalName attribute:
$ env KRB5CCNAME=$TMPDIR/test kinit -k; env KRB5CCNAME=$TMPDIR/test klist
Ticket cache: FILE:/tmp/myuser-0ZyB7rKb/test
Default principal: host/myclient.example.org(a)EXAMPLE.ORG
Valid starting Expires Service principal
2018-04-19 19:04:53 2018-04-20 19:04:53 krbtgt/EXAMPLE.ORG(a)EXAMPLE.ORG
renew until 2018-04-26 19:04:53
If you want to use --user-principal you have to set ldap_sasl_authid
explicitly in sssd.conf to the same value because the AD provider
will use a different default.
That isn't our experience. Our experience is that authenticating
against MYCLIENT$ explicitly also works:
$ env KRB5CCNAME=$TMPDIR/test kinit -k 'MYCLIENT$'; env
KRB5CCNAME=$TMPDIR/test klist
Ticket cache: FILE:/tmp/myuser-0ZyB7rKb/test
Default principal: MYCLIENT$(a)EXAMPLE.ORG
Valid starting Expires Service principal
2018-04-19 19:04:46 2018-04-20 19:04:46 krbtgt/EXAMPLE.ORG(a)EXAMPLE.ORG
renew until 2018-04-26 19:04:46
So:
With AD you can only get a TGT for the principal in
userPrincipalName or if this is not set for sAMAccountName(a)AD.REALM
To clarify: it's an "OR" condition, not an "XOR" condition. You
can
always get a TGT for the sAMAccountName; if userPrincipalName is set,
then you can also get a TGT for the userPrincipalName.
This is why, when we first starting joining our Linux hosts to AD, we
explicitly set the userPrincipalName to "host/fqdn@REALM" when we
joined: it seemed like the correct thing to do, because it was very
clearly what "kinit -k" was expecting by default.
More simply put, it's a lot easier to script this:
kinit -k
…than this:
# WOW THIS IS UGLY
kinit -k "$(hostname -s | tr '[[:lower:]]'
'[[:upper:]]')\$"
…especially because /etc/krb5.conf is dumb and doesn't have any way to
set the default principal target of "kinit -k".
If you want to get rid of the RestrictedKrbHost entries in the
keytab using '--service-name=host' with adcli should work. The
documentation here is a bit unclear, it will not add more entries
but override the default 'host' and 'RestrictedKrbHost'.
As an alternative, after joining without additional options you can
use ktutil to remove unwanted entries from a keytab. Nevertheless
the RestrictedKrbHost should not do any harm.
Eh, we're not worried about those. I was more curious than anything
else, because "net ads join" doesn't create them, and we've never had
any Kerberos service break because they weren't present.
Anyway, I was going to suggest updating the documentation, but I see
Jakub already beat me to it!
Thanks,
James