On Fri, 2005-01-14 at 15:20, Aleksandar Milivojevic wrote:
> > Yes, the bits and pieces are all there, although I'm not sure the
> > mail part is really standard (do sendmail/postfix/cyrus all use
> > the same thing, and what about aliases and groups?), but how useful
> > is it if you can't expect all versions to match? You also need a
> > tool that populates all of the common fields at once. By default
> > you probably want the posix, samba, and email accounts to match
> > without typing them again and you'll want to change passwords in
> > one place and affect them all. Redhat/fedora has the market share
> > to become the standard if they just shipped something that came up
> > working as installed. I doubt if anyone else can do that now.
>
> I don't see where's the problem. You want user to have attributes from
> posixAccount? Add posixAccount to list of his objectClass(es), and than
> you can add attributes that are defined in that class, and use LDAP as
> replacement for NIS.
The problem is that I want to be able to install my next hundred
boxes running an assortment of OS versions that I don't know
about yet, and have them find whatever attributes they need
already available. I don't want to have to tweak the server
every time I add a new service. In fact I want it to work without
the person adding a new box/service having access to modify the
LDAP server.
> You want to add Sendmail LDAP mail routing for
> that user, add inetLocalMailRecipient to list of his objectClass(es),
> and add attributes such as mailLocalAddress or mailRoutingAddress. You
> don't create separate tree for every service that needs to store data
> about user. You add object classes needed to describe user to his
> objectClass attribute, and than you add service specific attributes.
But isn't this already well enough understood to just be included
in one standard format?
> As for passwords, old style Windows passwords needed to support older
> Windows implementations are not compatible with more or less anything.
> So those will have to be separate. Even in Active Directory, they are
> stored as base64 representation of UTF8 plaintext password. The reason
> is basically the same as behind using smbpasswd file. More or less
> anything else should be happy with userPassword attribute. If all your
> Windows clients are 2000 and newer, Kerberos in combination with Cyrus
> SASL might save you there (depending on your actual configuration, and
> what really you want/need to implement). Either have Windows side
> authenticate against Unix-side Kerberos server, or have slapd use
> Windows side Kerberos server to authenticated against Active Directory
> domain (use {SASL}username@xxxxxxxxxxxxx as value for userPassword
> attribute). Works both way.
OK, again - this hasn't changed recently and there are bits and pieces
of tools that change passwords in all the needed places. Why
can't it come up working as installed?
> If you don't like fiddling with LDIF files in vi editor, use GUI tools
> such as gq, jxplorer, and/or ldapbrowser (there are probably others).
> Those are general purpose tools (basically GUI versions of
> ldapsearch/add/modify), however they do the job fairly well. The only
> thing Fedora folks might do, IMHO, is to include one of them into
> distribution (probably gq, since jxplorer and ldapbrowser are Java
> applications, and they don't work with gcj, or at least I couldn't get
> them to work with anything but Sun's Java).
I don't really want to know that I'm modifying things in LDAP to
add a user or change a password. The tool that adds users should
do all the grunge work. If it needs to store the password in
3 different format to work, it should do it. I think there are
such tools - the problem is that there is more than one and they
probably don't all interoperate.
> Want something more custom made for your installation (rather than
> general tools)? There are easy to use Perl and PHP LDAP modules that
> will let you develop whatever interface for managing users you might
> wish. You type add_user.pl, and script sets up user in LDAP database
> whatever way you want.
No, I don't want a custom tool - I don't want to need a custom tool.
I want a stock schema that provides all the attributes that all the
tools in the base distribution know how to use, and a standard tool
that populates them. Anything else seems as bizarre as having to
decide on your own fields and layout of the passwd file before you
could add any users. What is it about LDAP that has kept it from
being standardized years ago?
--
Les Mikesell
les@xxxxxxxxxxxxxxxx
