Thanks for confirmation. Regards Tarun Chopra
Sent from my Windows Phone ________________________________ From: Matthieu Patou Sent: 10/29/2012 9:16 PM To: Tarun Chopra Cc: Edgar Olougouna; [email protected] Subject: Re: GetRevealSecretsPolicyForUser On 10/25/2012 08:52 AM, Tarun Chopra wrote: > Hi Matthieu > > We have updated MS-ADTS specification with 2 new groups [Allowed RODC > Password Replication Group and Denied RODC Password Replication Group] in > section 6.1.1.6 (Well-Known Domain-Relative Security Principals), details as > follows : > > > 6.1.1.6.16 Allowed RODC Password Replication Group > name: Allowed RODC Password Replication Group > objectClass: group > RID: 571 > groupType: { GROUP_TYPE_RESOURCE_GROUP | GROUP_TYPE_SECURITY_ENABLED } > > > > 6.1.1.6.17 Denied RODC Password Replication Group > name: Denied RODC Password Replication Group > objectClass: group > RID: 572 > groupType: { GROUP_TYPE_RESOURCE_GROUP | GROUP_TYPE_SECURITY_ENABLED } > > > Allowed RODC Password Replication Group and Denied RODC Password Replication > Group are, by default, added to attributes msDS-RevealOnDemandGroup and > msDS-NeverRevealGroup respectively during dcpromo; therefore, there is no > extra processing needed---following the processing rules as documented in > MS-DRSR section 4.1.10.5.14 and MS-ADTS section 3.1.1.4.5.32 will give the > correct results. Oh I missed this point, is it also in the changes that you'll publish for MS-ADTS ? > These attributes (msDS-RevealOnDemandGroup and msDS-NeverRevealGroup) are > maintained by an administrator and implementations must not take a dependency > on any specifics of their contents. Also see section 6.1.1.3.2 of MS-ADTS for > more information related to these attributes. > > Kindly let us know if above information resolves your query or you require > any further clarification. Yes all of this make sense now that I understand that it's the group that is added to the msDS-[RevealOnDeman|NeverReveal]Group not the content of the group. Matthieu. > Thanks > Tarun Chopra. > > From: Edgar Olougouna > Sent: Friday, October 19, 2012 8:08 AM > To: [email protected]; [email protected]; Tarun Chopra > Subject: RE: GetRevealSecretsPolicyForUser > > Matthieu, > I am adding my colleague Tarun Chopra who will take care of this while I will > be on vacation. > > Thanks, > Edgar > ________________________________ > From: Matthieu Patou > Sent: 10/18/2012 1:06 PM > To: Edgar Olougouna; [email protected]<mailto:[email protected]> > Subject: Re: GetRevealSecretsPolicyForUser > Hello Edgar, > > On 10/17/2012 10:21 AM, Edgar Olougouna wrote: >> Matthieu, >> >> There will be an update to MS-ADTS and I will communicate the change as soon >> as the draft is ready. >> However, the algorithm in MS-DRSR already covers the required processing. >> Allowed RODC Password Replication Group and Denied RODC Password Replication >> Group are by default added to attributes msDS-RevealOnDemandGroup and >> msDS-NeverRevealGroup respectively during dcpromo, therefore there is no >> extra processing needed, following the processing rules as documented in >> MS-DRSR 4.1.10.5.14 GetRevealSecretsPolicyForUser will get the right >> results. These attributes (msDS-RevealOnDemandGroup and >> msDS-NeverRevealGroup) are maintained by an administrator and >> implementations must not take a dependency on any specifics of their >> contents. More information relating to these attributes can be found in >> 6.1.1.3.2 MS-ADTS 6.1.1.3.2 Read-Only Domain Controller Object . > So if I read you right then it means that those groups are used only at > (rodc)dcpromo to populate the attributes that are used for checking in > MS-DRSR 4.1.10.5.14. > > Did you verify this behavior ? > This article: > http://technet.microsoft.com/en-us/library/rodc-guidance-for-administering-the-password-replication-policy%28v=ws.10%29.aspx, > seems to indicate that it's a constant check > " <javascript:void(0)> > Reviewing the accounts that are authenticated to an RODC > <javascript:void(0)> > ------------------------------------------------------------------------ > > You should periodically review the accounts that have been authenticated > to an RODC. This information can help you plan updates that you intend > to make to the existing PRP. For example, you may want to review which > user and computer accounts have authenticated to an RODC so that you can > add those accounts to the Allowed List. > > ImportantImportant > You will probably see more accounts in the *Accounts that have been > authenticated to this Read-only Domain Controller* list than will have > passwords cached. Although you may see accounts of writeable domain > controllers or members of the Domain Admins group in the list of > authenticated accounts, it does not necessarily indicate that those > accounts authenticated to the domain through the RODC. Instead, it means > that the RODC in one way or another verified the credentials of those > accounts. All default administrative accounts and domain controllers are > denied explicitly or through their membership from having their > passwords cached. If there are additional accounts that you want to make > sure are not cached, include them in the Deny list or make them members > of the Denied RODC Password Replication Group. The Deny list comprises > of the accounts that are specifically denied in the PRP from caching > their credentials on the RODC. > > " > > Thanks. > > Matthieu > > -- > Matthieu Patou > Samba Team > http://samba.org > > -- Matthieu Patou Samba Team http://samba.org
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
