Groups with Samba+LDAP PDC: schema, help needed
kevin_myer at elanco.k12.pa.us
Tue Jun 29 21:30:48 GMT 1999
On Tue, 29 Jun 1999, Charles Owens wrote:
> Thanks very much! I can now see the "default" NT groups! I was a bit
> spooked by them not being around. ;-) I was able to add other users
> to the various groups by adding addtional member attribute values of
> the form:
> member: ntuid,rid,1 # any idea what the "1" is for?
> Some remaining questions:
> * Adding groups:
> o From the sambaGroup schema and your example LDIF I think it's fairly
> clear what additional group entries would look like. Are there any
> working automated techniques for adding groups, or am I stuck
> manually tweaking ldap enties? (I can't seem to use usrmgr.exe to
> actually make changes, just view stuff... what about you?)
I'd say you're stuck manually adding entries for the time being.
> o If I have to do it by hand... I'm guessing that I'll have to look up
> the "nextrid" attribute from the sambaConfig entry to determing the
> rid for the new group, create the group, and then update "nextrid".
Yep - should be easy to do with perl. I'm not at the stage of user tools
yet - but I think I'm pretty darn close to having the backend working and
once thats working, its tool creation time. And may the Samba team will
have the RPCs implimented for using User Manager for Domains by then and I
won't have to worry about it.
> * Unix<->Domain group mapping:
> o I very much liked how the non-LDAP PDC auto mapped Unix groups to
> Domain groups. Anyway to achieve this with similar ease in the
> with-LDAP PDC context?
Maybe add gidnumber to the dn for each group? I.e. add the UNIX group ID
number to the NT group DN entry. Haven't thought this one through yet. I
personally am using pam_ldap and nss_ldap for uid and gid stuff so that
solves the problem for me
> BTW, your sambaGroup and sambaBuiltin objectclass definitions were missing a
> few attributes. Here they are again, tweaked enough to get your LDIF to load,
> though who knows if they're formally correct...:
No warranties, guaranteed or implied in anything I turn out :) I was
hoping to find a formal RFC or an extension to RFC 2307 for the Samba
stuff but didn't find anything so I reverse engineered what I thought
could or should be in there.
I also found a way to get around the password expired problem today and I
sheepishly admit maybe its not as much a bug as I would expect.
Basically, if the pwdMustChange attribute doesn't exist, that variable is
initialized to zero time in the UNIX world. Since we aren't back in 1969
anymore, naturally any password aging is expired (unless its set to only
require changes every 20 years :) So what I did was create the attribute
and put a bogus future value into it. Now my password doesn't expire
until sometime in 2004 and the prompt to change goes away.
I would think a more desireable behavior than setting the
pass_must_change_time portion to the Stone Age would be to assume that if
it doesn't exist, it means that the password doesn't expire. Of course,
then we have to define some time far off in the future and thats what the
COBOL programmers did back in the 70's and now we're living in infinity
~ Kevin M. Myer
. . Network/System Administrator
/V\ ELANCO School District
More information about the samba-ntdom