-----BEGIN PGP SIGNED MESSAGE-----
On 08/13/2013 02:27 PM, Wes Modes wrote:
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
[root@samba ~]# useradd wchandy useradd: user 'wchandy' already
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
add local users in the presence of ldap authentication.
Generally speaking, this is a *Bad Idea*. Why are you trying to do
this? You don't want to mix users with the same name on your systems.
The only reason I can think that you would want this is because you
want this user to have a different UID and/or group memberships
locally. In that case, they really *are* different users and should be
named differently to avoid confusion.
If you absolutely have to do this, then you should filter out the user
from LDAP by adding them (and that UID, most likely) to the
'filter_users' option in sssd.conf. That way, they are never returned
by SSSD and therefore cannot be in conflict.
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. I want to be able to keep doing this, AND add more
users like this when needed.
Please stop doing this. You're going to regret it. Using the same
username for users with different UIDs is a recipe for disaster.
* 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 now any
new local entry interferes with the same user's access to samba.
The underlying problem is that you are intentionally making poor
naming decisions. Why not use 'local-wchandy' since they ARE NOT THE
SAME USER as far as Linux is concerned. Don't confuse yourself.
* No, I don't want to rely on ldap for local ssh login.
Why? That's what SSSD is for: to make sure that info is cached so it
can survive an LDAP outage.
* No, I don't want to use a different uid for the user.
Wait, what? You just said above that these were the same username with
different UIDs. If you're just mirroring the LDAP value, stop. SSSD's
caching has already solved that problem for you. It's persistent and
much more reliable than nscd caching used to be.
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,
I used 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 =
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
debug_level = 31 |
As a workaround I came up with two non-optimal solutions. It at
As a workaround to *what*? You haven't mentioned what failed to work
gave me a way of moving forward after I found myself in the sticky
situation where LDAP and the local passwd file are blocking each
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
Again, *why*? SSSD is already doing the caching on the local machine.
- From Linux's perspective, it's pretty much the same as what you've
done, except we've done it with more careful planning to be able to
handle changes made on the LDAP server.
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.
I'm pretty sure you've just missed the main benefit of SSSD: it makes
that unnecessary. If you had a different experience, then that's an
SSSD *bug* and we can get it fixed for you. But we need to know what
was the inciting incident that made you believe you have to use local
Thanks for the help. If I can get my local and samba-ldap
authentication working independently I'll be stoked.
Systems Designer, Developer, and Administrator University Library
ITS University of California, Santa Cruz
_______________________________________________ sssd-users mailing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----