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. 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.
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.
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).
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.
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
