Can't add local user on system using ldap auth for samba

Question

Trying to add a local user to a CentOS 6.3 system that is using ldap for Samba authentication, but being stymied by the user's existing entry in ldap.

[root@samba ~]# adduser wchandy
adduser: user 'wchandy' already exists

[root@samba ~]# useradd wchandy
useradd: user 'wchandy' already exists

User is not already a local user:

[root@edgar2 ~]# grep wchandy /etc/passwd

But they are a Samba user in ldap:

[root@edgar2 ~]# smbldap-usershow wchandy | grep uid
dn: uid=wchandy,ou=people,dc=ucsc,dc=edu
uid: wchandy
uidNumber: 30490

adduser does not have a local option. How does one get adduser to work properly to add local users in the presence of ldap authentication.

Other things to consider:

• There are currently local users who share a uid with an ldap entry (with a different uidNumber) who can access samba and ssh independently.
• No, I don't want to edit the user directly into /etc/passwd and /etc/group. I'd like to fix the underlying problem. Plus the local entry interferes with access to samba.
• No, I don't want to rely on ldap for local ssh login.
• No, I don't want to use a different uid for the user.

I originally set up my samba-ldap authentication with the handy (but seemly irreversible) authconfig command:

[root@samba ~]# authconfig --enableshadow --enablemd5 --enableldap \
--enableldapauth --enableldaptls --enablemkhomedir \
--ldapserver=dir.mydomain.com --ldapbasedn="dc=mydomain,dc=com" \
--enablelocauthorize --updateall

My /etc/sysconfig/authconfig looks like this:

IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
PASSWDALGORITHM=sha512
FORCELEGACY=no
USEFPRINTD=yes
USEHESIOD=no
FORCESMARTCARD=no
USEDB=no
USELDAPAUTH=yes
IPAV2NONTP=no
USELDAP=yes
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELOCAUTHORIZE=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=no
USEPASSWDQC=no

My samba config was migrated from an RHEL4.x system to CentOS 6.3. Now instead of the kludgy mashup of nss and pam and who knows what, CentOS 6.x uses the pretty slick and easy sssd.

My /etc/sssd/sssd.conf looks like this:

[domain/default]

cache_credentials = True
#cache_credentials = False
ldap_search_base = dc=mydomain,dc=com
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://dir.mydomain.com/
ldap_tls_cacertdir = /etc/openldap/cacerts
#ldap_tls_reqcert = allow

entry_cache_timeout = 5

debug_level = 31

[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
# domains = LDAP
domains = default

#debug_level = 31

[nss]

[pam]

debug_level = 31

Thanks for the help. If I can get my local and samba-ldap authentication working independently I'll be stoked.

UPDATE: While there are some reasonably sufficient workarounds below, here's a parapharse of the advice I got from the experts at the sssd_users list: "Yes, it may have worked in earlier OS versions using nss and pam, it wasn't the best practice to allow shared UIDs. Newer systems using sssd prevent this." While my use case was perfectly valid, my system prevented what I wanted to do by intention.

However, I never did find a way to unset or reverse any of the many changes that authconfig wrought to my system. So if the parameters I gave to authconfig were wrong, there was no going back.

Solution 1

Neither of these two workarounds are optimum, but they do give sysadmins a way of moving forward if they find themselves in the sticky situation where LDAP and the local passwd file are blocking each other.

Workaround 1: I created a local user with a different UID (username) to give ssh access to a person who already had an LDAP/Samba entry. Possibly the cheeziest sysadmin solution I've done in years.

Workaround 2: A little more complicated but comes down to adding the local user with the same uidNumber as in LDAP.

1. Lookup LDAP uidNumber with getent, ldapsearch, or smbldap-usershow
2. Temporarily disable the user in LDAP in order to add the local user without conflicts
3. Create the local account matching the uidNumber with LDAP
4. Re-enable the user in LDAP

Both of these work, but neither address the underlying issue of allowing the authentication to use LDAP exclusively for Samba auth and /etc/passwd for local auth. But in the absence of another solution, this will have to do.

Solution 2

My last answer was bad, ignore that.

I believe your only option is manual editing of /etc/passwd (vipw is preferred because it saves you from your own mistakes). The -o option allows you to create multiple names for one UID, but there isn't an equivalent option for telling passwd to ignore the name already existing when it performs a NSS lookup.

getent passwd will show you how the uids cascade once you've added the user; the first entry wins. Make sure the uid is identical to avoid issues with shifting permissions. (your examples did not include -u syntax)

Comments

[Andrew B]

Keep in mind that sssd is consumed by NSS and PAM; it does not replace them. You still need to understand those services and how they interact with it.

[Wes Modes]

I am definitely not an NSS, PAM, or sssd expert, I feel like I should still be able to effectively configure it. No answer to this question has yet been offered.

[Wes Modes]

This does not answer the original inquiry, but I had to find some temporary workaround: I created a local user with a different UID to give ssh access to a person who already had an LDAP/Samba entry. Possibly the cheeziest sysadmin solution I've done in years.

[Wes Modes]

Okay another workaround, still less than optimal: Adding the local user with the same uidNumber as the LDAP entry. That allows both local and Samba access.

[Andrew B]

Fixing the underlying problem unfortunately means working with the software authors or submitting a patch yourself. We cannot help you do something that the command simply does not support.

[Andrew B]

Additionally, your edit now adds conflicting logic: you want the useradd command to work despite the duplicate username, but adding local entries manually interferes with samba? Please edit your question to focus on the specific problem you want solved.

[Wes Modes]

Andrew, I appreciate your taking the time to respond, and I don't think the request is unreasonable nor confusing. To be concise: I want to know how to configure sssd, nss, and pam (preferably with the authconfig tool) to allow local authentication exclusively from /etc/passwd while allowing Samba to use LDAP exclusively for authentication. In fact, I had a RHEL4 system configured precisely this way.

[Wes Modes]

And I strongly believe this is a configuration issue, a gap in my understanding of the complex systems involved, not a software engineering issue. The authors would no doubt have an answer to my query, and perhaps that is where I should seek. There is a mailing list for sssd users.

[Andrew B]

At least for me, the presentation wasn't very clear. Between the subject and How does one get adduser to work properly to add local users in the presence of ldap authentication., your intent shifts more toward "how do I get useradd to let me do this" than "how do I dis-entangle these two services". If you edit the question to focus on your actual intent from the beginning, it'll probably pass the re-open queue and we'll take another shot at it.

[Wes Modes]

No I don't think this question was unclear. I edited the title to better reflect the problem.

[Andrew B]

Looking at things again I think I have a better idea of what you're looking for; I just think we were just talking around each other in circles. Drop by this SF chat if you still need help and we'll work it out without spamming this question.

[Wes Modes]

Thanks, Andrew. The workarounds were sufficient. It's been a while, but I believe the answer I finally got from the sssd_users list is: "Yes, it may have worked in earlier versions, but it wasn't the best practice to allow shared uids. Newer versions prevent this." While my use case was perfectly valid, sssd (which replaced some of the other systems cobbled together with dental floss and chewing gum) doesn't allow it." In fact, I should add this to the original question. Thanks!

[Andrew B]

If you need to untie passwd lookups from sssd, remove sssd from the corresponding entry in /etc/nsswitch.conf (unless there's a daemon that breaks by doing this). You really can't get away from understanding NSS and PAM when doing elaborate overlays. sssd is implemented by modules for both, and is not a replacement.

[Wes Modes]

Please see above: "No, I don't want to edit the user directly into /etc/passwd and /etc/group. I'd like to fix the underlying problem. PLUS THE LOCAL ENTRY INTERFERES WITH ACCESS TO SAMBA." So, unfortunately, no, that isn't a solution.