We faced this exact question for the exact same reason a year and a half ago. The main problems are threefold:
- Novell networks are historically drive-letter based. Everyone knows that the U: drive is for their user's home directory and S: is for Shared. And so on.
- Microsoft networks are much less attached to drive-letters and Microsoft has been pushing UNC style addressing since the advent of Active Directory. Long-established Microsoft houses tend to use whatever is at hand for drive letters, with a few standard ones for old apps that require a drive-letter.
- Users haaaaaaate changing established procedures. They simply will NOT throw drive-letters over the side in favor of UNCs, and will continue to call the helpdesk with "The Y: drive is down."
Because of 1 and 3, we were still using drive letters a year after our Microsoft migration. Users are slooowly getting used to UNC addressing for a few things, but our Shared volume, a massive, monolithic volume, needed to be split up due to size reasons on the SAN. Rather than force everyone to deal with UNCs, we figured out how to do directory-mounted volumes in a cluster.
If you have the option (such as very few Mac users) Microsoft DFS can make things a lot easier here. Create a single drive-letter, with the top-level directories being, in essence, the old drive-letter mapping. In a pure Windows environment this can work well. Anything that uses Samba, though, can't use it. Users just have a single drive letter, and the move from 14 drive-letters to a single one with paths like "S:\K-Drive\" is dead easy. We have a lot of Mac users, so couldn't go this route.
The drive-letters we have standardized in our login-script (another hold-over from the Novell days):
- P: = The monolithic Shared volume
- S: = Student classwork volume (usage slowly decreasing as everything moves to Blackboard)
- U: = Home directory
- W: = End-user software repository
- X: = Certain network-installed software packages, mainly focused around our ERP system
- Y: = Admin scripts and things
We also operated a drive-letter registry in our Windows Admin group. If a drive gets mapped in a login script, it gets documented who is doing it. This saves a lot of grief if two departments want to map a T: drive to different places, and happen to share staff.
The standards I can recommend are:
- Keep centrally mandated drive letters to a minimum.
- Operate a drive-letter registry in your overall Admin coordination group
- If needed, periodically audit your drive-mapping methods against what you expect them to be.
The approach I use now is SSSD. It's quite painless and the configuration files are clean. SSSD can be enabled at install time or just run via the authconfig
command UI. I recently converted ~200 Linux servers to SSSD from local auth and used the steps below.
This assumes a Red Hat-like system (RHEL, CentOS, Fedora)...
1) Download SSSD.
yum install sssd
2). Modify the system's authconfig settings.
authconfig --enablesssd --ldapserver=ldap://dc1.mdmarra.local
--ldapbasedn="dc=mdmarra,dc=local" --enablerfc2307bis --enablesssdauth --krb5kdc=dc1.mdmarra.local --krb5realm=MDMARRA.LOCAL --disableforcelegacy --enablelocauthorize --enablemkhomedir --updateall
3). Update the /etc/sssd/sssd.conf configuration file contents with the following:
# sssd.conf
[domain/default]
ldap_id_use_start_tls = False
ldap_schema = rfc2307bis
ldap_search_base = dc=mdmarra,dc=local
krb5_realm = MDMARRA.LOCAL
krb5_server = dc1.mdmarra.local
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://dc1.mdmarra.local,ldap://dc2.mdmarra.local
krb5_kpasswd = dc1.mdmarra.local,dc2.mdmarra.local
krb5_kdcip = dc1.mdmarra.local,dc2.mdmarra.local
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_force_upper_case_realm = True
ldap_user_object_class = person
ldap_group_object_class = group
ldap_user_gecos = displayName
ldap_user_home_directory = unixHomeDirectory
ldap_default_bind_dn = ldapuser@mdmarra.local
ldap_default_authtok_type = password
ldap_default_authtok = fdfXb52Ghk3F
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[sudo]
[autofs]
[ssh]
Best Answer
They both can do the same, it's just with
usermod
you can do it wrong if you don't pay enough attention.In this wiki from Arch Linux (it is the same for other distros), it's explained: