sssd-users September 2014

sssd-users@lists.fedorahosted.org

15 participants
23 discussions

ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder 18 Mar '15

18 Mar '15

HI! Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs? In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd. Ciao, Michael.

5 22

Re: [SSSD-users] rocks cluster user mgmt
by Nordgren, Bryce L -FS 06 Oct '14

06 Oct '14

This is kind of a tangent, as we're moving off into discussing authentication solutions for rocks, so I renamed the thread. > Wouldn't using constrained delegation (s4u2proxy) + HBAC would be a better > solution for this use case? > Then you do not need to manage SSH keys. You would need to define which > hosts are allowed to be "gateways" and make sure it is complemented by > corresponding HBAC policies. Proud to say that's a question for the rocks developers. This rocks user is not going to be retooling anything. Guidance on how to join the cluster to AD is here: https://wiki.rocksclusters.org/wiki/index.php/Configuring_Windows_AD_Authen…. It involves samba, winbind, and setting up Kerberos, then syncing those files to all the compute nodes. The headnode is joined to AD, but I don't think the compute nodes are (they don't have a presence on the network AD can see, so what would their host/fqdn(a)AD.REALM be?) I don't see them setting up a KDC on the headnode. Long story short, I think the headnode will kinit to AD, jobs are still run by using SSH key, and compute nodes have the option of allowing users to authenticate via SSH key or kinit, but SSO shouldn't work. (haven't tried it, tho so I may have missed something) A likely first step would be to run IdM on the headnode (or a dedicated service node) to manage all the compute nodes, import the AD users via trust and get SSO working. At this stage, you'll figure out if there's issues with people's favorite clustering filesystem, queue manager, or the MPI libraries. Worry about constraints and such later on....if they were to attempt it at all. Unless HBAC is a lot more dynamic than I think it is, it's unlikely to be useful. The rules would really need to be under control of the queueing system, since that is the entity which dispatches jobs to the cluster. My understanding, though, is that the HPC/grid computing world is pretty heavily invested in PKI rather than Kerberos technologies. (RFC3820 for history and status) > IdM allows to do it now and latest Fedora/RHEL/CentOS should be able to do > it now. > IdM does not expose the management of the delegation yet (but it can be > done using LDAP modify, ugly but possible) but this is being added in 4.1. > > https://fedorahosted.org/freeipa/ticket/3644 Current Rocks is based on CentOS/RHEL 5 and 6. It may be when they retool for CentOS/RHEL 7 they will consider it, but I certainly can't speak for them. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

2 11

Using SSSD Cache When Online
by Matt Hughes 29 Sep '14

29 Sep '14

I have an Nginx server that uses a PAM module for authorization. PAM module talks to SSSD which talks to an LDAP server. Currently, every request to the web server ends up making a request to the LDAP server. I’m trying to take advantage of SSSD’s caching mechanisms to improve response time. I know the SSSD cache works because if I block my connection to the LDAP server, my requests still complete, and very quickly. What I’d like is to be able to use this cache even if the LDAP server is marked as ‘working’. My pam file is: auth required pam_sss.so account required pam_sss.so I was hoping this flag is what I wanted: entry_cache_timeout (integer) How many seconds should nss_sss consider entries valid before asking the backend again Default: 5400 My reading of that is SSSD wouldn’t go back to the LDAP server for the same user until 5400 seconds have occurred. Is that incorrect? I have that set (along with cache_credentials=true) and I can only get it to read from cache if it thinks the server is down. Here is my full sssd.conf file: https://gist.github.com/matthughes/05aaeaf276fe5ecafddc

3 2

root login with domain passwd
by Joakim Tjernlund 27 Sep '14

27 Sep '14

>>> Don't quite follow here. I do have a local root user in passwd/shadow >>> with >>> a >>> local pw as required by any UNIX I know. I also have a AD root account. >> >> Lets get this straight, you have a user called 'root' in /etc/passwd >> and another user called 'root' in AD, is this correct ??? > >You should name your central user something else. SSSD will deliberately >not authenticate root because root should be authenticated by pam_unix. That should be my decision, not enforced by SSSD. Jocke

3 4

root login with domain passwd
by Joakim Tjernlund 26 Sep '14

26 Sep '14

>> Lets get this straight, you have a user called 'root' in /etc/passwd >>> and another user called 'root' in AD, is this correct ??? >> >> You should name your central user something else. SSSD will deliberately >> not authenticate root because root should be authenticated by pam_unix. >> >Hi >How about deleting the user called root in AD, choosing another domain >user called adroot. Then use: >username map = /some/file >to make adroot map to root in /some/file? > >adroot is now a domain user with uid 0 Possibly one can do that, but this is just a bad workaround for a bad assumption in SSSD, namly that there can not be any system out there who would like to auth "root" with SSSD. Jocke PS. Keep me on CC

2 1

root login with domain passwd
by Joakim Tjernlund 26 Sep '14

26 Sep '14

>> Don't quite follow here. I do have a local root user in passwd/shadow with >> a >> local pw as required by any UNIX I know. I also have a AD root account. > >Lets get this straight, you have a user called 'root' in /etc/passwd and >another user called 'root' in AD, is this correct ??? Yes PS. Why is it so hard to keep me on CC? Some list setting which makes this easy to forget? > >Rowland

3 2

root login with domain passwd
by Joakim Tjernlund 26 Sep '14

26 Sep '14

>Joakim Tjernlund wrote: >> How is local root pw any different than domain pw? In your view remote >> root access is a big nono so sssd should also enforce no remote root login in >> that case. > >Yes, remote root password is a big no-no. Because it would be effective on all >systems at once circumventing most security mechanisms. You missed the point. You claim remote root is a nono yet you suggest to login remotely with local root pw. > >I really appreciate sssd denying root completely. Most people concerned about >security surely agree. But it don't. sssd does not deny remote local root pw logins. > >If you personally don't like this important aspect of sssd just use something >else. > >> You just said it: "best practice", not a law. In this context, sssd >> dictates policy >> and that is not sssd's call to make IMHO. You should encourage best >> practice though. >> One day we will get there but not today :) > >It seems you don't have proper operational processes on your side to handle >incidents and lock out your users from doing something bad. Then you ask for a >significant security relevant change in a widely used component. That sucks. But I don't. I just ask for the possibility choose. Let the default be as is. PS. Please keep me on CC Jocke > >Ciao, Michael.

8 13

Re: [SSSD-users] root login with domain passwd
by Joakim Tjernlund 25 Sep '14

25 Sep '14

>On Wed, Sep 24, 2014 at 06:57:54PM +0200, Joakim Tjernlund wrote: >> Trying to figure how to setup sssd to allow me to ssh into another box as >> root using the domain root passwd. > >It's not possible by design, SSSD explicitly drops all requests for >either root or UID 0. root is really a machine-local administrator, >nothing that should be present on the remote servers. Thanks, I can stop trying then. This should be clearly stated somewhere though. > >> Nothing I tried lets me do that so could someone please give me an example >> config which >> lets root in with domain passwd? > >Why do you need this? Because as an admin I need to login on users boxes to fix stuff they broke. Sometimes su/sudo are not setup/broken too. > >If your goal is to have the same root password across an enterprise, I >recommend something like Puppet or Ansible. How does that help me to ssh in and what if Puppet/Ansible is not setup/broken? Not every box is installed the same. > >If the goal is to let users administer machines, then storing sudo rules >in LDAP is the best way forward. That we have but I am looking for easy admin access. sssd should not dictate way of working. Admins should be able to change this behaviour, especially since this a new sssd specific rule and makes it harder for existing IT environments to migrate to sssd. Keep as default but let me override please. PS. Please CC me as I am not on the list.

6 9

root login with domain passwd
by Joakim Tjernlund 25 Sep '14

25 Sep '14

Trying to figure how to setup sssd to allow me to ssh into another box as root using the domain root passwd. Nothing I tried lets me do that so could someone please give me an example config which lets root in with domain passwd? Jocke

3 2

SSSD returns inconsistent results in a AD forest with mixture of 2003 R2 and 2008 R2 based controllers
by Prajwal Kumar 24 Sep '14

24 Sep '14

I'm trying to integrate SUSE Linux (version 11 Patch level 2) with Microsoft Active Directory(AD) using the SSSD version 1.9.4 for making AD groups available to the Linux OS subsystem (SSSD is not used for authentication) I've added the "sss" as a source for "passwd", "group", "shadow" within the "/etc/nsswitch.conf" file. I'm seeing SSSD return inconsistent results while fetching the User/Group information through "id" / "getent" commands. It appears that we are facing this inconsistency only while SSSD interacts with Domain Controller with version Windows Server 2008 R2, and not while SSSD is interacting with Windows Server 2003 R2 based domain controller. Please find the response/output from Linux host (terminal) as below: 1) For Windows Server 2008 R2 based Domain Controller controller@indelappvm02:~> id user_hadoop_3001 uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2115887,2812298(Mygroups-hadoop-DAS_ANALYST),2812208(Mygroups-hadoop-CV_US),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2827118(Mygroups-hadoop-DAS_ALL),2819228(Mygroups-hadoop-IMAGINE_GED_LON),2820642(Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-OPEX),2024985,2356240,2358411,2100126,2115932,2099 968,2337579,1743308,1463380,2100236,1881724,1707456 As can be seen above, certain GIDs are displayed though these are not relevant to the user. When I query the same user again in the same session, I get the correct results without the additional GIDs. The problem re-appears when the cache has been cleared and the command is re-run. 2) For Windows Server 2003 R2 based Domain Controller controller@indelappvm02:~> id user_hadoop_3001 uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2812208(Mygroups-hadoop-CV_US),2819228(Mygroups-hadoop-IMAGINE_GED_LON),2827118(Mygroups-hadoop-DAS_ALL),2812298(Mygroups-hadoop-DAS_ANALYST),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2820642(Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-OPEX) The results are always accurate. Would appreciate your inputs in helping solve this problem in case you have encountered this in your environment. SSSD config is attached. Regards, Prajwal

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2014