[SSSD] [PATCHES][PRELIMINARY] Add support for Active Directory objectSID mappings

Stephen Gallagher sgallagh at redhat.com
Mon Apr 23 11:27:55 UTC 2012


On Mon, 2012-04-23 at 10:56 +0200, Sumit Bose wrote:
> On Fri, Apr 20, 2012 at 03:01:17PM -0400, Stephen Gallagher wrote:
> > On Fri, 2012-04-13 at 12:34 +0200, Jan Zelený wrote:
> > > 
> > > Hi Stephen,
> > > I went through all patches and I have couple things which I'd like to ask you 
> > > about. First of all I'm not that familiar with ID mapping in winbind so my 
> > > questions might be trivial. If yes, sorry for that.
> > > 
> > > First thing: I'd like to know a bit more about those slices, range and this 
> > > sort of stuff. I mean like the background and ideas behind it. It might be a 
> > > good thing to include some information or pointers to other documentation into 
> > > our man pages.
> > > 
> > 
> > Yes, as I mentioned in the patches, I need to write manpages for these
> > things. So the main topics are lower and upper limits, ranges and
> > slices.
> > 
> > The lower and upper limit provides the minimum and maximum pool of IDs
> > that we can draw from. Rangesize is how many IDs will constitute a
> > single slice. So each slice contains rangesize uids and there are
> > rangesize / (upper-lower) available slices. Each slice will hold the IDs
> > for one domain.
> > 
> > So in the default case:
> > ldap_idmap_range_min = 100,001
> > ldap_idmap_range_max = 2,000,100,000
> > ldap_idmap_range_size = 100,000
> > 
> > 
> > So what this means is that we will have 2000 available slices each
> > capable of managing up to 100,000 IDs.
> > 
> > > About the general approach I have only one comment. I don't really like two 
> > > different approaches to storing the domain sid - as string and as a struct. 
> > > Would it make any sense to unify all ID mapping code to be working with one 
> > > data format?
> > > 
> > 
> > Well, the ID-mapping library that Sumit wrote takes the string format,
> > so I was working with that. However, it's difficult at best to get there
> > from the representation stored in LDAP without converting it through the
> > struct. Unless Sumit wants to change the ID-mapping library to take
> > struct dom_sid, it's probably fine to just leave this as-is.
> > 
> > I could have made the conversion function a single one, but it seemed
> > potentially handy to have them be separate.
> 
> I tried to keep the idmap library simple and tried to avoid adding
> functionality which I did no need. But I think is would make sense to
> enhance the interface to allow the usage of binary SIDs and struct
> dom_sid as well.
> 
> Stephen, what do you think of adding the definition of struct dom_sid
> and the conversion calls to the idmap library? I you prefer I can do it
> and then you can rebase your patch on top of the new version of the
> idmap library?

Sure, I'm amenable to that. If you want to do it, that would be
preferable to me. I've still got a lot of work to do for the 1.9 beta
release.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120423/81ce1136/attachment.sig>


More information about the sssd-devel mailing list