[IPA] Storing SID in String Format

[Andrew Bartlett]

On Thu, 2009-10-01 at 12:43 +1000, Andrew Bartlett wrote:
> On Wed, 2009-09-30 at 15:58 -0400, Endi Sukma Dewata wrote:
> > Hi Andrew,
> > 
> > Sorry for the long pause after our last conversation. I've been
> > working on several proposals which are quite related to each other.
> > 
> > The first one that I want to discuss with you is about storing
> > SID in string format:
> > http://www.freeipa.org/page/Samba_4_Storing_SID_in_String_Format
> 
> A thorough and full description of the problem, and a good proposal for
> the solution.  (and exactly what I expected - that is very similar to
> the way we do exactly this for the objectGUID). 
> 
> Some work will need to be done to change the generated schema to use a
> different syntax for only one object.  Alternately, it can be told to
> skip objectSID, and know that you will otherwise provide it. 

Actually, I have a better idea.  When you are able, use the name Samba3
uses.  That way we are not further diverging the schemas folks will find
on the net.  (sambaSid is the name for a string-format SID in Samba3). 

> > That is a prerequisite for utilizing DNA plugin for SID allocation:
> > http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin
> 
> This proposal looks very reasonable. 
> 
> > And just so you know, I'm also looking for a way to resolve the
> > conflicts between AD schema and standard LDAP schema:
> > http://www.freeipa.org/page/Samba_4_Attribute_Type_Mapping
> 
> This looks like a good way to re-use that well-used and understood
> codepath in Samba to achieve your goals.  (It also needs someone to love
> it for better performance). 
> 
> > That is a prerequisite for deploying Samba into an existing FDS
> > instance which contains standard LDAP schema:
> > http://www.freeipa.org/page/Samba_4_Provisioning_Existing_DS_Instance
> 
> I really like that!  I fully agree that the changes we make to Fedora DS
> should be made by the ProvisionBackend class - as a function.  We should
> just have a 'finish and shutdown' method on that class (with
> implementations for OpenLDAP and Fedora DS).   
> 
> > Also, the FDS support is currently still not working because there
> > are still some issues related to SASL and schema. I'm working with
> > the DS team to get this fixed by DS 1.2.3. Here's some info about it:
> > http://www.freeipa.org/page/Samba_4_Authentication_Using_SASL
> 
> Great!
> 
> > So for now I'd like to get your opinion about the first proposal.
> > Is this pretty much in line with what we've discussed before?
> 
> Even more than that - it's what we discussed, fleshed out the the
> logical conclusions and sensible design.  I'm very impressed!
> 
> You may wish to look further into how you can use the ldb_map code to
> reduce the need to store both tree formats.  I realise you have already
> chosen the tree layout, but for example if samba was to use 'uid' for
> samAccountName, it might be one less thing to have your Fedora DS side
> tool synchronise.  A logical extension of this thorough the rest of the
> simple cases might allow objects to be shared (or at least only renamed,
> not renamed and munged). 

See also the unloved but still mostly-passing-the-testsuite 'samba3sam'
mapping module.  I would strongly suggest rather than just renaming all
the attributes with a 'Samba4' prefix, that you try and map them to the
right thing in your target schema, or the Samba3 schema.  We don't need
more schemas out there. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091001/801fb49f/attachment.pgp>