Bug 13377 - Authentication fails to an RODC if the user is in the Denied Replication list
Summary: Authentication fails to an RODC if the user is in the Denied Replication list
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.8.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 13879 14865
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-10 17:29 UTC by Alex MacCuish
Modified: 2022-03-19 16:31 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex MacCuish 2018-04-10 17:29:33 UTC
Expected behaviour: Authentication is proxied to a writable DC

Problem: Even when an RODC is online, it fails to authenticate users whose passwords are denied from being replicated (e.g. Domain Admins). Samba (winbind) correctly contacts a writable samba DC, but the writable DC not only denies the single object replication request later, but also the initial authentication attempt. This affects simple binds to ldap and gssapi binds (the initial kerberos tickets can't be retrieved).

The writable DC logs:

../source4/rpc_server/drsuapi/getncchanges.c:1205: DRSUAPI_EXOP_REPL_SECRET extended op on <GUID=951c8b5a-5156-4555-89b2-9e9f67da3f5c>;CN=Administrator,OU=People,OU=Domain Users,DC=xxx,DC=xxx,DC=xxx

../source4/rpc_server/drsuapi/getncchanges.c:1358: Denied single object with secret replication for CN=Administrator,OU=People,OU=Domain Users,DC=xxx,DC=xxx,DC=xxx by RODC CN=DC03,OU=Domain Controllers,DC=xxx,DC=xxx,DC=xxx

1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 refused for security token on DC=xxx,DC=xxx,DC=xxx

Using a service ticket obtained from a writable DC works.
Comment 1 Garming Sam 2019-03-28 22:48:19 UTC
Kerberos RODC forwarding isn't implemented (yet) and LDAP simple binds rely on having the password stored locally (I'm not sure what the case is on Windows, but I would be somewhat surprised if this worked).

There should be tests of NTLM gssapi working.

The replication failing is entirely what you would expect (and will always trigger in case you've moved the user from the denied replication list).
Comment 2 Garming Sam 2019-03-31 21:17:57 UTC
(In reply to Garming Sam from comment #1)

As Andrew has corrected on the list, it's only the bad password forwarding that isn't complete with Kerberos. In the good case, and with the user not being preloaded, this should work.

I don't believe there are any tests of the simple bind working in Samba.