LDAP schema

[Luke Kenneth Casson Leighton]

On Fri, 27 Nov 1998, Matt Chapman wrote:

> Jean Francois Micouleau wrote:
> 
> > On Fri, 27 Nov 1998, Matt Chapman wrote:
> >
> > > A number of those attributes aren't of very much use to us though; they
> > > only surface at certain info levels which it would be absurd to add
> > > passdb routines for, or provide functionality which won't be in Samba
> > > while we are still tied to the existing databases. And in a few years
> > > time who knows what we'll need...
> >
> > Check again, most of them are in the user_info_21 struct.
> 
> OK, at a glance at least the following aren't (but I'm not trying to be
> provocative here).
> 
> objectSid

probably the SID+rid.

> adminCount

dunnu.

> badPasswordTime
> badPwdCount

yes, these are in SAM, haven't been able to identify them.

> codePage

in, not yet id'd.

> controlAccessRights

don't know

> countryCode

in, not yet id'd.

> groupMembershipSAM

don't know.

> lmPwdHistory
> localeID
> loginCount

don't know.

> logonWorkstation

list of 8 workstations, in there.


> maxStorage
> ntPwdHistory
> operatorCount

don't know.

> otherLoginWorkstations

probably related to logonWorkstation.

> policyName
> policyOptions
> preferredOU
> securityDescriptor
> revision

dunno.

> 
> 
> > > Maybe we need a whole new strategy for obtaining user & group
> > > information...  perhaps something along the lines of open_user,
> > > get_user_attribute (so that an extensible set of attributes could be
> > > queried), close_user... Well, it would certainly make the LDAP
> > > implementation easier :-)
> >
> > Why do you think the passdb.c API is for ? That's exactly what we done
> > Luke and I in April/May ! It was all abstracted in an API exacly because I
> > wanted to store more attributes in the LDAP database than what was
> > available in the smbpasswd file.
> 
> The passdb.c API manipulates smb_passwd, sam_passwd, and sam_disp_info
> structures. There may be other pieces of information that we may in the future
> want to store about users, for instance the list above (badPwdCount et al
> especially).

then we add them, because if they exist, then there will exist API calls
in nt that support them.  microsoft is doing all the hard work, here :-)
:-)
 
> Are we going to add new functions to each password database for every new
> USER_INFO_xx that has some new piece of information that we can't get from
> existing data?

what we will do, as and when we discover a MS-API that is made by an nt
server or workstation, is to find out what USER_INFO_xx or other info
level is travelling over-the-wire, work it out and add it.

> Do we need to retrieve a whole sam_passwd struct when all we
want > is one attribute?

yes, unless you want to help write a more advanced version of the password
database API which mirrors more closely what NT does: they support tens of
"INFO" levels.  for now, methinks that is not a high priority, but if you
think it might be then i'm game :-)
 
> Anyway the passdb.c API is definitely a good thing and will serve our current
> needs. I was just daydreaming, don't take any notice :-)
> 
> 
> > > I would like to see what Luke has to say on the issue of storing RIDs, SIDs,
> > > etc. as opposed to generating them..., but certainly in the schema I'll be
> > > adding a few more attributes to those in that example.
> >
> > We debated this already with Luke and Jeremy some months ago.
> > The standard case is where the users don't have any RID, you generate them
> > based on the UID, using Jeremy's mapping.
> >
> > The second case, is when you're migrating from an NT-Domain to a
> > Samba-Domain, and you want to keep the RID
> 
> OK. Will store RIDs and use them if they are available.

thanks.
 
> 
> > > I did have a look at Microsoft's AD docs before and they seem to go into their
> > > new NT5 groups schema in great detail but not say very much about individual
> > > user information... was I looking in the wrong place?
> >
> > Last time I checked the AD schema on MS web server was outdated. You have
> > to find an NT5 beta 2 CD to have the latest version.
> 
> If I see one floating about I will have a look. In the meantime, I will stick by
> Luke's comment - "unix is more important" :-)

did i say that??? nooo, jeremy said that: he keeps reminding me.  me, i
give both NT and UNIX equal absolute top priority.  why?  because i know
it can be done.