[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sssd-users
Subject:    Re: [SSSD-users] Can't add local user on system using ldap auth for samba
From:       Stephen Gallagher <sgallagh () redhat ! com>
Date:       2013-08-14 12:13:33
Message-ID: 520B746D.5010301 () redhat ! com
[Download RAW message or body]

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlILdG0ACgkQeiVVYja6o6NWQwCfQMBPb9YOojxo0K+PyiFiJBle
TZ0An1LUinGIUZtsI66WfnOzIOZL7xqT
=535N
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[prev in list] [next in list] [prev in thread] [next in thread]