On Wed, Apr 18, 2018 at 01:51:38PM -0400, James Ralston wrote:
On Tue, Apr 17, 2018 at 2:27 AM, Sumit Bose <sbose(a)redhat.com>
wrote:
> On Mon, Apr 16, 2018 at 04:28:59PM -0400, James Ralston wrote:
>
> > Has anyone figured out how to make sssd utilize a Microsoft
> > read-only Domain Controller (RODC)?
> >
> > But no matter how we create the computer account object, or how we
> > export the Kerberos keytab, sssd cannot use the resulting keytab
> > file to authenticate to the RODC: when sssd sends the AS-REQ, the
> > RODC always replies with KRB5KDC_ERR_PREAUTH_FAILED.
>
> If 'kinit -k' works, SSSD should work as well.
Thanks; that's good to know.
> Can you send the SSSD logs with debug_level=9, most important would
> be the domain log and the ldap_child.log files.
>
> For comparison it would be good to see the output of
>
> KRB5_TRACE=/dev/stdout kinit -k ....
>
> as well.
OK, I will look into that. (KRB5_TRACE especially seems like it will
be useful; I wasn't aware of that.)
I think part of why we're struggling here is because the behavior of
sssd doesn't seem to match its documentation.
Specifically…
For RWDCs, when I use Samba "net ads join" to create the computer
account in AD and write the /etc/krb5.keytab file, it always creates
multiple entries:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/myhost.example.org(a)EXAMPLE.ORG (des-cbc-crc)
2 host/myhost.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myhost.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myhost.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myhost.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/MYHOST(a)EXAMPLE.ORG (des-cbc-crc)
2 host/MYHOST(a)EXAMPLE.ORG (des-cbc-md5)
2 host/MYHOST(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/MYHOST(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/MYHOST(a)EXAMPLE.ORG (arcfour-hmac)
2 MYHOST$(a)EXAMPLE.ORG (des-cbc-crc)
2 MYHOST$(a)EXAMPLE.ORG (des-cbc-md5)
2 MYHOST$(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYHOST$(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYHOST$(a)EXAMPLE.ORG (arcfour-hmac)
Using "adcli" does much the same thing, but additionally creates
RestrictedKrbHost SPNs:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 MYCLIENT$(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (des3-cbc-sha1)
2 MYCLIENT$(a)EXAMPLE.ORG (arcfour-hmac)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-md5)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-crc)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/MYCLIENT(a)EXAMPLE.ORG (arcfour-hmac)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-md5)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG
(aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG
(aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
For adcli, this is the corresponding computer object in AD:
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName:
myclient.example.org
userPrincipalName: host/myclient.example.org(a)EXAMPLE.ORG
Did you call adcli with the --user-principal option?
I would expect that without this option the userPrincipalName attribute
will not be set and 'MYCLIENT$(a)EXAMPLE.ORG' would be the default user
principal.
servicePrincipalName:
RestrictedKrbHost/myclient.example.org
servicePrincipalName: RestrictedKrbHost/MYCLIENT
servicePrincipalName:
host/myclient.example.org
servicePrincipalName: host/MYCLIENT
If use Samba to join the host to AD, the account is the same, minus
the RestrictedKrbHost SPNs.
According to the sssd-ldap(5) man page, ldap_sasl_authid defaults to:
host/hostname@REALM
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 ...
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.
For the principals listed in servicePrincipalName you can get a service
ticket but not a TGT.
I'm not sure.
But at least for AD, this doesn't seem to be what sssd is doing. We
don't set ldap_sasl_authid, but for hosts joined to a RWDC with a
keytab like the examples above, we can see in packet captures that
sssd defaults to using SHORTHOSTNAME$:
As said above this is expected for the SDDD AD provider because by
default the user principal used by AD for hosts is
SHORTHOSTNAME$(a)AD.REALM.
Kerberos AS-REQ
Pvno: 5
MSG Type: AS-REQ (10)
padata: PA-ENC-TIMESTAMP Unknown:149
Type: PA-ENC-TIMESTAMP (2)
…
Type: Unknown (149)
Value: <MISSING>
KDC_REQ_BODY
Padding: 0
KDCOptions: 00000010 (Renewable OK)
Client Name (Principal): MYCLIENT$
Name-type: Principal (1)
Name: MYCLIENT$
Realm:
EXAMPLE.ORG
Server Name (Service and Instance):
krbtgt/EXAMPLE.ORG
Name-type: Service and Instance (2)
Name: krbtgt
Name:
EXAMPLE.ORG
till: 2018-04-13 20:11:22 (UTC)
Nonce: 462670550
Encryption Types: …
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: aes128-cts-hmac-sha1-96 (17)
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-crc (1)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-md5-nt (20)
Encryption type: Unknown (19)
Encryption type: des3-cbc-sha1 (16)
Encryption type: Unknown (25)
Encryption type: Unknown (26)
Encryption type: des-cbc-md4 (2)
This behavior is why we've been trying to export a Kerberos keytab
file from AD that looks *exactly* like one that samba/adcli would
create. As we've discovered, that's not trivial.
But if in fact we don't need those additional entries—that just the
host/myclient.example.org(a)EXAMPLE.ORG entry in the keytab file is
sufficient for sssd—then that would help us immensely.
So: if the only thing in the /etc/krb5.keytab file is this:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/myclient.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
…and the corresponding machine account in AD is:
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName:
myclient.example.org
userPrincipalName: host/myclient.example.org(a)EXAMPLE.ORG
servicePrincipalName:
host/myclient.example.org
Should that be sufficient for sssd to work correctly?
Yes, but 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?
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.
If you use adcli without additional options the userPrincipalName
attribute should not be created in the host object and the defaults of
the AD provider should work.
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.
HTH
bye,
Sumit
>
> Thanks,
> James
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org