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
