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:


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:


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

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



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.

closed as unclear what you're asking by Andrew B, Ward, mdpc, Brent Pabst, dawud Aug 13 '13 at 16:03

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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. – Andrew B Jul 26 '13 at 21:25
  • 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 Aug 9 '13 at 21:28
  • 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 Aug 9 '13 at 21:31
  • 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. – Wes Modes Aug 9 '13 at 22:11
  • 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 Aug 9 '13 at 23:27

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)

  • 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. – Wes Modes Aug 9 '13 at 21:27

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.