[PATCH] ldap connection caching (not ready!!!)
Andrew Bartlett
abartlet at samba.org
Fri Oct 18 09:35:00 GMT 2002
"Stefan (metze) Metzmacher" wrote:
>
> At 10:30 18.10.2002 +0200, Ignacio Coupeau wrote:
> >Stefan (metze) Metzmacher wrote:
> >!!! a few line above I read 'return NT_STATUS_OK' but it
> >>was 'ret = NT_STATUS_OK' :-(
> >>but now it works! :-)
> >>what I need is to test is the non_unix_account stuff.
>
> Should this mail a responde to the id allocator patch???
>
> >I browsed the code and the ldap schema changes... if I don't
> >misunderstand, the the nextrid is used only for non_unix_account, and the
> >algorithmic mapping for unix accounts, rigth?
>
> there is no nextrid attribute in HEAD or 3_0
But we want to add one - and I want it for non-unix accounts. What I
propose is that we get the nextrid idea bedded down in non-unix
accounts, then expand it from there when we figure out the other issues.
> >So, the other question is if a non_unix_account should be in only-one
> >domain? In other words: if an user logs in the domain x the ldap stuff
> >will provide a rid-x only useable for the domain-x?
> >
> >I wonder if this may be a strong restriction for large sites with "n"
> >domains and only-one ldap base... because the administrators should
> >maintain n accounts/rid per-user for access to the n domains. On the other
> >hand, if the domain attr takes n-values may solve the multiple logon but
> >the rid space may be broken.
>
> you can have only one samba domain in one ldap tree, all samba related
> objects have only a rid and a full sid and the attribute 'domain' is not
> used at the moment.
Well, you should be able to have more than one domain per ldap tree - we
should use the ldap suffix, and the ldap search filter to allow it.
Andrew Bartlett
--
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical
mailing list