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

Sumit Bose sbose at redhat.com
Mon Apr 23 08:56:32 UTC 2012


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?

bye,
Sumit

> 
> 
> > One comment to the code: please rename those constants at the beginning of 
> > sdap_idmap.c (like SDAP_IDMAP_MAPPING_FILTER) to SYSDB_....
> 
> Sure, will do.



> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list