[Bcc dochelp] Andrew, Here are some initial material. The MS-KILE reference gives some pointers on RODC implementation. I'll dig further and see whether there is any "authenticated at RODC flag".
RODC implementation has the notion of branch id (for a branch office) for the RODC's KDC. I'd think it's based the site the account is located at, so it shall start from DC location. I don't expect authentication failure going out on the WAN link to a WDC/PDC to be substantially different due to an RODC, but I'll take a look. Along the same line, I am thinking of a case where the account password has changed but not replicated yet to the DC. the following article describes the RODC authentication process and the forwarding to WDC. https://technet.microsoft.com/en-us/library/cc754218(v=ws.10).aspx#BKMK_AuthRODC MS-KILE 3.3.5.7.7 Read-only Domain Controller (RODC) https://msdn.microsoft.com/en-us/library/hh536320.aspx When a Key Distribution Center (KDC) which is a read-only domain controller (RODC) receives: An AS-REQ message with a PA-PAC-OPTIONS [167] (section 2.2.10) padata type with the forward to full DC bit set, the RODC SHOULD forward the AS-REQ to a full DC. A TGS-REQ message with a PA-PAC-OPTIONS [167] (section 2.2.10) padata type with the Branch Aware bit set, and the application server (SNAME) is not in its database, the RODC SHOULD return server principal unknown with the substatus message of NTSTATUS STATUS_NO_SECRETS ([MS-ERREF] section 2.3.1). 2.2.10 PA-PAC-OPTIONS https://msdn.microsoft.com/en-us/library/hh553950.aspx PA-PAC-OPTIONS ::= SEQUENCE { KerberosFlags -- Claims (0) -- Branch Aware (1) -- Forward to Full DC (2) } Thanks, Edgar -----Original Message----- From: Nathan Manis [mailto:[email protected]] Sent: Friday, November 25, 2016 8:19 AM To: Andrew Bartlett <[email protected]>; [email protected] Cc: MSSolve Case Email <[email protected]> Subject: RE: Authenticated at RODC flag? 116112514986292, 116112514986305 [case mail to cc:, dochelp to bcc:] Hi Andrew, Thank you for contacting the open protocols team. Two cases have been created to assist in answering the questions. The case numbers are as follows: 116112514986292, Authenticated at RODC flag? Is there a flag lag or special SID that indicated the a session is authenticated at the RODC 116112514986305, Where is the fallback to the PDC documented, when a user authenticates (by any means) to an RODC but the password isn't there, or wasn't correct? A member of the open protocols team will be in contact to assist further. Thanks, Nathan Manis -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Friday, November 25, 2016 12:18 AM To: Interoperability Documentation Help <[email protected]>; [email protected] Subject: Authenticated at RODC flag? I remember somewhere there being a flag or special SID that indicated the a session is authenticated at the RODC. However I can't find any evidence of it. Is there any such flag, ideally for connections made to the LDAP server, to tell me if the user session was authenticated at the RODC, or if the authentication was passed to the full DC? I realise I could do a SamLogonEx or Kerberos login and get the logon_sever from the info3/PAC, but I want to know the full set of options I have. This will help me test the fall-back from the RODC to the full DC for Samba, and the subsequent replication of the secrets (if permitted). Also, where is the fallback to the PDC documented, when a user authenticates (by any means) to an RODC but the password isn't there, or wasn't correct? Thanks, Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT https://catalyst.net.nz/services/samba _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
