[SSSD-users] does sssd support using a Microsoft read-only Domain Controller (RODC)?

[James Ralston]

Has anyone figured out how to make sssd utilize a Microsoft read-only
Domain Controller (RODC)?

The host we want to join to AD is already behind the RODC. So, we are
trying to "join" the host to the RODC by pre-creating a computer
account object in AD (via a RWDC), then exporting a Kerberos keytab
file to install on the client host.

On the client host, in the /etc/krb5.conf file, we have overridden the
"kdc" setting for our domain, pointing it to the RODC. In
/etc/sssd/sssd.conf, we have set "ad_server" for our domain, pointing
it to the RODC. Using the exported keytab file, we can run "kinit -k"
successfully.

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.

I'm beginning to suspect that sssd just doesn't work with RODCs: if
"kinit -k" can successfully authenticate and acquire a service
principal using the keytab file we exported to the client from the
RWDC, then why can't sssd successfully use it?

Can anyone confirm that you have sssd successfully speaking to a
Microsoft RODC?

If so, did you join the client host to a RWDC and then move it behind
the RODC? Or did you pre-create the machine account on the RWDC and
export the Kerberos keytab to the client? If the latter, do you have
the exact net/admod/ktpass commands you used to pre-create the
computer account and export the keytab in a way that is compatible
with sssd?

Thanks in advance for any pointers or advice!
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email

[Sumit Bose]

Post by James Ralston
Has anyone figured out how to make sssd utilize a Microsoft read-only
Domain Controller (RODC)?
The host we want to join to AD is already behind the RODC. So, we are
trying to "join" the host to the RODC by pre-creating a computer
account object in AD (via a RWDC), then exporting a Kerberos keytab
file to install on the client host.
On the client host, in the /etc/krb5.conf file, we have overridden the
"kdc" setting for our domain, pointing it to the RODC. In
/etc/sssd/sssd.conf, we have set "ad_server" for our domain, pointing
it to the RODC. Using the exported keytab file, we can run "kinit -k"
successfully.
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.
I'm beginning to suspect that sssd just doesn't work with RODCs: if
"kinit -k" can successfully authenticate and acquire a service
principal using the keytab file we exported to the client from the
RWDC, then why can't sssd successfully use it?

If 'kinit -k' works, SSSD should work as well. 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.

bye,
Sumit

Post by James Ralston
Can anyone confirm that you have sssd successfully speaking to a
Microsoft RODC?
If so, did you join the client host to a RWDC and then move it behind
the RODC? Or did you pre-create the machine account on the RWDC and
export the Kerberos keytab to the client? If the latter, do you have
the exact net/admod/ktpass commands you used to pre-create the
computer account and export the keytab in a way that is compatible
with sssd?
Thanks in advance for any pointers or advice!
_______________________________________________

_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to ss

[James Ralston]

Post by Sumit Bose

Post by James Ralston
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.

Post by Sumit Bose
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/***@EXAMPLE.ORG (des-cbc-crc)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (arcfour-hmac)
2 host/***@EXAMPLE.ORG (des-cbc-crc)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@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/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (des3-cbc-sha1)
2 host/***@EXAMPLE.ORG (arcfour-hmac)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (des-cbc-crc)
2 host/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (des3-cbc-sha1)
2 host/***@EXAMPLE.ORG (arcfour-hmac)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/***@EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/***@EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/***@EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/***@EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/***@EXAMPLE.ORG
(aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/***@EXAMPLE.ORG
(aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/***@EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/***@EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/***@EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/***@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/***@EXAMPLE.ORG
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/***@REALM

However, this is ambiguous. Does this mean:

host/***@REALM

…or does it mean:

host/***@REALM

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$:

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/***@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/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (des3-cbc-sha1)
2 host/***@EXAMPLE.ORG (arcfour-hmac)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (des-cbc-crc)

…and the corresponding machine account in AD is:

sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName: myclient.example.org
userPrincipalName: host/***@EXAMPLE.ORG
servicePrincipalName: host/myclient.example.org

Should that be sufficient for sssd to work correctly?

Thanks,
James
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-

[Sumit Bose]

Post by James Ralston

Post by Sumit Bose

Post by James Ralston
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.

Post by Sumit Bose
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
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
Using "adcli" does much the same thing, but additionally creates
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
(aes256-cts-hmac-sha1-96)
(aes128-cts-hmac-sha1-96)
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName: myclient.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.

Post by James Ralston
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.

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 ...
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
***@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.

Post by James Ralston
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

As said above this is expected for the SDDD AD provider because by
default the user principal used by AD for hosts is

Post by James Ralston
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
sufficient for sssd—then that would help us immensely.
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName: myclient.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

Post by James Ralston
Thanks,
James
_______________________________________________

_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@li

[Jakub Hrozek]

Post by Sumit Bose
Unfortunately there is a special behavior of the AD provider which is
default, see below ...

Hmm, I don’t know why we never documented this, but we should: https://github.com/SSSD/sssd/pull/555
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-***@li

[James Ralston]

Post by Sumit Bose
Unfortunately there is a special behavior of the AD provider which
is not documented in the man page which would use

OK…

Post by Sumit Bose
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
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…

Post by Sumit Bose
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/***@EXAMPLE.ORG (des-cbc-crc)
2 host/***@EXAMPLE.ORG (des-cbc-crc)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (des-cbc-md5)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/***@EXAMPLE.ORG (arcfour-hmac)
2 host/***@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/***@EXAMPLE.ORG
servicePrincipalName: HOST/myclient.example.org
servicePrincipalName: HOST/MYCLIENT

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

Valid starting Expires Service principal
2018-04-19 19:04:53 2018-04-20 19:04:53 krbtgt/***@EXAMPLE.ORG
renew until 2018-04-26 19:04:53

Post by Sumit Bose
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
renew until 2018-04-26 19:04:46

Post by Sumit Bose
With AD you can only get a TGT for the principal in

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/***@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".

Post by Sumit Bose
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
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe s