ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder
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.
8 years, 6 months
Re: [SSSD-users] rocks cluster user mgmt
by Nordgren, Bryce L -FS
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_Auth.... 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.
8 years, 11 months
Using SSSD Cache When Online
by Matt Hughes
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
8 years, 12 months
root login with domain passwd
by Joakim Tjernlund
>>> 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
8 years, 12 months
root login with domain passwd
by Joakim Tjernlund
>> 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
8 years, 12 months
root login with domain passwd
by Joakim Tjernlund
>> 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
8 years, 12 months
root login with domain passwd
by Joakim Tjernlund
>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 years, 12 months
Re: [SSSD-users] root login with domain passwd
by Joakim Tjernlund
>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.
8 years, 12 months
root login with domain passwd
by Joakim Tjernlund
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
9 years
SSSD returns inconsistent results in a AD forest with mixture of 2003 R2 and 2008 R2 based controllers
by Prajwal Kumar
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
9 years
