[cifs-protocol] GetRevealSecretsPolicyForUser

[Matthieu Patou]

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: mat at samba.org; cifs-protocol at samba.org; 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; cifs-protocol at samba.org<mailto:cifs-protocol at samba.org>
> 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