From: alex@milivojevic.org
Nope. On Windows during login users usually selects domain part from drop-down box (yes, you can type it too if you want).
[ Not that this matters, but ... ]
First off, that's _only_ for the GINA portion, and not always. Unless you take the time to distribute all domains either at the server or client, you won't always see all domains.
Secondly, inside of various apps, credentials are not always passed correctly, which requires the nomenclature. Of course, the application can save the username and other settings in the application itself. E.g., try to login to IIS' FTP server when you have multiple domains. ;-> You'll have to pass the DOMAIN/user nomenclature in many cases.
And usually whatever domain is selected in that drop-down box by default is the correct one for the owner of the particular PC.
[ Again, not that it matters, but ... ]
And the same can be said for applications on a UNIX system with a particular user's login, and their configuration files (and mounted home directory -- you are automounting home directories, yes?).
I'm kinda scratching my head here. I can setup a user's IMAP credentials in various applications (both Windows and UNIX/Linux) to remember their username for the setup, so that is avoided.
I don't see the difference between multiple REALMs and multiple NTDOM/ADSDOMs. If you properly configure the login/apps to remember the user's domain, then it's not an issue.
Anyhow, historically real Unix accounts were used on email servers, so after switch to virtual accounts requirement was that users don't notice the change. Higher authority decided that it would be too complicated for non-technical population to swtich from "username" to "username@REALM".
[ Lastly, also mot that it matters, but ... ]
What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before?
NOW WHAT MATTERS ...
_Please_ read up on how NsDS works. It's _extremely_ "enterprise class" and much more capable than OpenLDAP, which was more of an "open framework" of different capabilities (not always well integrated).
http://www.redhat.com/docs/manuals/dir-server/ag/ssl.htm
"Netscape Directory Server Administrators Guide Chapter 11 ... Configuring Kerberos Kerberos v5 must be deployed on your system to utilize the GSS-API mechanism for SASL authentication ... ... Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP URL:
uid=<user_name/[server_instance]>,cn=realm,cn=mechanism,cn=auth "
Is that more of what you were looking for? How to put the Realm in the uid?
-- Bryan J. Smith mailto:b.j.smith@ieee.org
Quoting "Bryan J. Smith b.j.smith@ieee.org" thebs413@earthlink.net:
What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before?
I'm abusing the fact that all users have accounts on one of AD domains. The "Unix" services are not aware of it. They simply authenticate user against flat userspace on LDAP server, and the LDAP/saslauthd component is smart enough to contact appropriate AD domain. So, no I'm not using Kerberos as such, because in reallity the clients users have can't use it either (reason is simple, most Windows software don't talk neither Kerberos nor SASL - they are all username/password based with option to pass it over SSL/TLS). I'm simply abusing the fact I can authenticate against AD domain using Kerberos as protocol.
So the question is. If I have user-a and user-b, where user-a exists as principal user-1@domain-1, and user-b exists as principal user-2@domain-2, can I have FDS authenticate the user against appropriate domain if passed only the "id=user-a,dc=mydomain,dc=com" or "id=user-b,dc=mydomain,dc=com"? No SASL, no Kerberos mumbo-jumbo all the way from the user's client software to LDAP server (what happens between LDAP server onwards can be anything, as long as it works).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.