-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/13/2013 02:27 PM, Wes Modes wrote:

Hi, all.

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 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:

|[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 |

As a workaround I came up with two non-optimal solutions. It at least

As a workaround to *what*? You haven't mentioned what failed to work for you.

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 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

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 users.

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

Wes

--

Wes Modes

Systems Designer, Developer, and Administrator University Library ITS University of California, Santa Cruz

_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users