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@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@EXAMPLE.ORG (des-cbc-crc) 2 host/myhost.example.org@EXAMPLE.ORG (des-cbc-md5) 2 host/myhost.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/myhost.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/myhost.example.org@EXAMPLE.ORG (arcfour-hmac) 2 host/MYHOST@EXAMPLE.ORG (des-cbc-crc) 2 host/MYHOST@EXAMPLE.ORG (des-cbc-md5) 2 host/MYHOST@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/MYHOST@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/MYHOST@EXAMPLE.ORG (arcfour-hmac) 2 MYHOST$@EXAMPLE.ORG (des-cbc-crc) 2 MYHOST$@EXAMPLE.ORG (des-cbc-md5) 2 MYHOST$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 MYHOST$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 MYHOST$@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$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 MYCLIENT$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 MYCLIENT$@EXAMPLE.ORG (des3-cbc-sha1) 2 MYCLIENT$@EXAMPLE.ORG (arcfour-hmac) 2 MYCLIENT$@EXAMPLE.ORG (des-cbc-md5) 2 MYCLIENT$@EXAMPLE.ORG (des-cbc-crc) 2 host/myclient.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (des3-cbc-sha1) 2 host/myclient.example.org@EXAMPLE.ORG (arcfour-hmac) 2 host/myclient.example.org@EXAMPLE.ORG (des-cbc-md5) 2 host/myclient.example.org@EXAMPLE.ORG (des-cbc-crc) 2 host/MYCLIENT@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/MYCLIENT@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/MYCLIENT@EXAMPLE.ORG (des3-cbc-sha1) 2 host/MYCLIENT@EXAMPLE.ORG (arcfour-hmac) 2 host/MYCLIENT@EXAMPLE.ORG (des-cbc-md5) 2 host/MYCLIENT@EXAMPLE.ORG (des-cbc-crc) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (des3-cbc-sha1) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (arcfour-hmac) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (des-cbc-md5) 2 RestrictedKrbHost/MYCLIENT@EXAMPLE.ORG (des-cbc-crc) 2 RestrictedKrbHost/myclient.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/myclient.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/myclient.example.org@EXAMPLE.ORG (des3-cbc-sha1) 2 RestrictedKrbHost/myclient.example.org@EXAMPLE.ORG (arcfour-hmac) 2 RestrictedKrbHost/myclient.example.org@EXAMPLE.ORG (des-cbc-md5) 2 RestrictedKrbHost/myclient.example.org@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@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$@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$@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@AD.REALM (MYCLIENT$@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$@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@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@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (des3-cbc-sha1) 2 host/myclient.example.org@EXAMPLE.ORG (arcfour-hmac) 2 host/myclient.example.org@EXAMPLE.ORG (des-cbc-md5) 2 host/myclient.example.org@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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org

On Thu, Apr 19, 2018 at 3:12 AM, Sumit Bose sbose@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$@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@AD.REALM (MYCLIENT$@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}@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@EXAMPLE.ORG (des-cbc-crc) 2 host/MYCLIENT@EXAMPLE.ORG (des-cbc-crc) 2 host/myclient.example.org@EXAMPLE.ORG (des-cbc-md5) 2 host/MYCLIENT@EXAMPLE.ORG (des-cbc-md5) 2 host/myclient.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/MYCLIENT@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/MYCLIENT@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 host/myclient.example.org@EXAMPLE.ORG (arcfour-hmac) 2 host/MYCLIENT@EXAMPLE.ORG (arcfour-hmac) 2 MYCLIENT$@EXAMPLE.ORG (des-cbc-crc) 2 MYCLIENT$@EXAMPLE.ORG (des-cbc-md5) 2 MYCLIENT$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96) 2 MYCLIENT$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96) 2 MYCLIENT$@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@EXAMPLE.ORG servicePrincipalName: HOST/myclient.example.org servicePrincipalName: HOST/MYCLIENT

The presence of the host/myclient.example.org@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@EXAMPLE.ORG

Valid starting Expires Service principal 2018-04-19 19:04:53 2018-04-20 19:04:53 krbtgt/EXAMPLE.ORG@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$@EXAMPLE.ORG

Valid starting Expires Service principal 2018-04-19 19:04:46 2018-04-20 19:04:46 krbtgt/EXAMPLE.ORG@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@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