Andrew,
We have completed our investigation of your request to include information
linking the structures in the backing store for LSA with the MS-LSAD documents.
We have focused on the methods related to trusted domain operations. The list
of these methods can be found in section 3.1.4.7. To summarize, all of these
methods deal with various aspects of manipulating/querying Trusted Domain
Objects as defined in section 7.1.6 of the MS-ADTS documentation.
We spoke about the method LsarSetTrustedDomainInfo so I also wanted to give you
some research information on this method to show how it ties to the MS-ADTS
documentation. LsarSetTrustedDomainInfo takes in two parameters that need to
be examined. Below is the MIDL for this method:
NTSTATUS LsarSetTrustedDomainInfo(
[in] LSAPR_HANDLE PolicyHandle,
[in] PRPC_SID TrustedDomainSid,
[in] TRUSTED_INFORMATION_CLASS InformationClass,
[in, switch_is(InformationClass)]
PLSAPR_TRUSTED_DOMAIN_INFO TrustedDomainInformation
);
If we look at the information class we start to unravel what objects the method
is working with. If InformationClass enum is set to
TrustedDomainNameInformation then the server must act as if an
LsarCreateTrustedDomain message came in. The TrustedDomainInformation object
would contain a LSAPR_TRUSTED_DOMAIN_NAME_INFO (MS-LSAD section 2.2.43) object.
We would then look at the LsarCreateTrustedDomain method information in
section MS-LSAD section 3.1.4.7.12 and see that in the processing section this
method must be processed in an identical manner to LsarCreateTrustedDomainEx.
This method also contains a processing note that this method must be processed
in an identical manner to LsarCreateTrustedDomainEx2. This method description
provides the link to MS-ADTS 7.1.6 in its description of the
TrustedDomainInformation structure.
Before we go into a mapping between the methods and the data structures let me
go back to LsarSetTrustedDomainInfo. If the information class is set to
TrustedDomainInformationEx then if the object does not exist, the server MUST
act as if an LsarCreateTrustedDomainEx message came in with
TrustedDomainInformation, which takes us to LsarCreateTrustedDomainEx2 to link
us to Active Directory as previously described.
Finally, if the InformationClass is set to TrustedPasswordInformation, then we
must process as if an LsarSetSecret request had been made. From the
documentation “The server MUST verify that a trusted domain object with this
SID exists in its policy database. If the object does not exist, the call MUST
fail with STATUS_NO_SUCH_DOMAIN.”
Now examining each of these calls and the information in 7.1.6 we can come up
with a mapping as follows for LsarSetTrustedDomainInfo:
1.) InformationClass == TrustedDomainNameInformation
SAPR_TRUSTED_DOMAIN_NAME_INFO->Name maps to name of TDO in System Container
(MS-ADTS section 7.1.6.7 and MS-ADSC 2.227)
2.) InformationClass == TrustedDomainInformationEx
LSAPR_TRUSTED_DOMAIN_INFORMATION_EX (MS-LSAD Section 2.2.54)
Name - MS-ADTS section 7.1.6.7 and MS-ADSC 2.227
FlatName - MS-ADTS section 7.1.6.7.1
Sid – MS-ADTS 7.1.6.7.8
TrustDirection – MS-ADTS 7.1.6.7.12
TrustType – MS-ADTS 7.1.6.7.15
TrustAttributes – MS-ADTS 7.1.6.7.9
3.) InformationClass == TrustedPasswordInformation
LSAPR_TRUSTED_PASSWORD_INFO (MS-LSAD section 2.2.46)
This can be any of the stored secret objects on the TDO such as
TrustAuthIncoming and TrustAuthOutgoing (MS-ADTS section 7.1.6.7.10 and
7.1.6.7.11)
If there is anything you may need additional information on please let us know
and we can provide further assistance.
Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving,
TX - 75039 "Las Colinas - LC2"
Tel: +1 469 775 7794
E-mail: [EMAIL PROTECTED]
We're hiring
http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted
________________________________________
From: Richard Guthrie
Sent: Friday, July 25, 2008 8:21 AM
To: Andrew Bartlett
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Mapping of MS-LSAD onto LDAP and DRS replications
Andrew,
I wanted to follow up on our conversation regarding LSA and your discussion on
its backing data store. I will also discuss security_descriptors and
privileges to complete the discussion. To start, all actions to the local LSA
datastore are done via the defined LSA interface in LSAD. There are two
scenarios that I will walk you through here. The first would be
querying/updating a local privledge. An example of this would be granting an
account/group that is a local/domain account the privledge ‘Log on locally’.
This is done via the local LSA interface. There is also some special cases
where LSA receives updates to global domain wide policy settings such as for
example Kerberos configuration settings like MaxTicketAge or MaxClockSkew.
These are commonly referred to as Domain LSA policies. These settings
maintained in a group policy object that is described in the following kb
article kb 324800 (http://support.microsoft.com/kb/324800).
LSA reads these values once they are picked up by Winlogon and applies then via
the process described in LSAD section 1.3. As you can see the only mechanism
for updating values in the LSA datastore is via the interface described in
MS-LSAD. It is for this reason from an interoperability perspective that we
define the datastore with an abstract interface leaving the decision on
implementation to the implementor. Some additional references for how these
Kerberos settings work with regard to group policy can be found in MS-GPOL and
MS-GPSB.
With regard to security descriptors, you can find documentation on this in
MS-DRSR and also MS-DTYP. MS-DRSR defines the security descriptor in section
5.15.2.6 String(NT-Sec-Desc) and 5.15.3.16 String(NT-Sec-Desc). You can cross
reference the example in 5.15.3.16 with MS-DTYP in section 2.4.6
SECURITY_DESCRIPTOR which provides the typedef for this type. These values are
replicated with DRS.
Please review and let us know if this answers your question?
Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving,
TX - 75039 "Las Colinas - LC2"
Tel: +1 469 775 7794
E-mail: [EMAIL PROTECTED]
We're hiring
http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted
-----Original Message-----
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 5:34 PM
To: Richard Guthrie
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Mapping of MS-LSAD onto LDAP and DRS replications
On Thu, 2008-07-17 at 08:20 -0700, Richard Guthrie wrote:
> Andrew,
>
> I think I have some answers for you but I wanted to clarify the
> question first. As I understand it, you are looking to get
> information on how objects sync’ed via Directory Replication Services
> (DRS) look to a receiving application, what is their layout, how are
> they exposed to the application that has requested the sync via a
> mechanism like IDL_DRSGetNCChanges in the DRSUAPI interface (MS-DRSR)
> with respect to privledge and access control structures. For example,
> if one were to replicate permissions or privledges between two domain
> controllers, what would that permissions object look like to the
> receiving domain controller and what would an application like the
> Local Security Authority (LSA) running on a domain controller see, how
> would it access them. Is this a correct interpretation of what you
> are looking for?
Pretty much. As I said, the SAMR documentation does a pretty good job of
defining the operation of the server into the attributes it uses,
where the LSA document describes only an abstract store.
The background is that I need to correct our LSA implementation to use a
compatible storage of privileges (in particular), so that if a privilege is set
on a Microsoft DC, that I can read it after replicating it using DRS to a Samba
DC.
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
