Install newer version of SSSD on CentOS 6.5
by Eric VS
Hi all,
I'm using SSSD for authentication against AD and it works like a charm so a
big thanks to all the developers. One thing I'm missing out on is the
newest options. CentOS 6.5 comes with version 1.9.2 of SSSD. The option I'm
looking for is the 'ad_access_filter' one which allows me to filter out
which users get access. I've been looking for an RPM for CentOS 6 for at
least version 1.11 for which is running on my machine and has the desired
option but cannot find it.
Any other options? Or anyone can point me to what I can do for an
alternative?
Kind regards,
*Eric Van Steenbergen*
*E-mail: vs.eric(a)gmail.com <vs.eric(a)gmail.com>*
9 years, 6 months
Re: [SSSD-users] Issues with v1.11.7
by Prajwal Kumar
I've cleared the cache /var/lib/sss/db/* and /var/lib/sss/mc/* and tried
starting sssd but get the same error. Surprisingly I don't have any issues
with 1.9.6 or 1.11.6! Wondering if there is any other idmap parameter that
I have to set to get it working on 1.11.7.
Best Regards,
Prajwal Kumar
+91-9886213418
On Thu, Oct 16, 2014 at 2:31 AM, Lukas Slebodnik <lslebodn(a)redhat.com>
wrote:
> On (15/10/14 22:39), Prajwal Kumar wrote:
> >Hi Sumit,
> >
> >When I set ldap_idmap_range_size = 4000000, SSSD fails to start:
> >
> >(Wed Oct 15 12:29:52 2014) [sssd[be[dbg]]] [sdap_idmap_init] (0x0100):
> >Initializing [6] domains for ID-mapping
> >(Wed Oct 15 12:29:52 2014) [sssd[be[dbg]]] [sdap_idmap_add_domain]
> >(0x1000): Adding domain [S-1-5-21-1606980848-1965331169-1417001333] as
> >slice [2392]
> ^^^^
> This number should not be higher than 500.
>
> Explanation:
> the default value of ldap_idmap_range_min is 200.000
> the default value of ldap_idmap_range_max is 2.000.200.000
> difference is 2.000.000.000
>
> You modified ldap_idmap_range_size to value 4.000.000
> * this option specifies the number of IDs available for each slice
>
> We have space for 2.000.000.000 IDs and each slice can contain 4.000.000
> IDs.
> So ther is space for 500 slices. The log file shows that sssd tried to
> store
> SID into slice with numer 2392.
>
> man sssd-ldap says (section ID MAPPING)
> Please note that changing the ID mapping related configuration options
> will cause user and group IDs to change. At the moment, SSSD does not
> support changing IDs, so the SSSD database must be removed.
>
> Please try to remove sssd cache (rm -f /var/lib/sss/db/*)
> I hope problem will be fixed after starting sssd with clean cache.
>
> LS
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
9 years, 6 months
(no subject)
by Prajwal Kumar
Hi,
I recently upgraded to 1.11.7 on my RHEL 6.5 box and have a problem getting
sssd work as the conversion from objectSID to Unix IDs fails. With a debug
level of 9 (this is the same config that worked in previous versions <
1.11.7 against the same AD forest), I see the below in sssd domain logs:
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_get_primary_name]
(0x0400): Processing object chantri
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x0400):
Processing user chantri
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x1000):
Mapping user [chantri] objectSID
[S-1-5-21-1611181143-1305343219-1050001001-2353897] to unix ID
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_idmap_sid_to_unix]
(0x0080): Could not convert objectSID
[S-1-5-21-1611181143-1305343219-1050001001-2353897] to a UNIX ID
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_user] (0x0020):
Failed to save user [chantri]
(Mon Oct 13 16:03:32 2014) [sssd[be[dbg]]] [sdap_save_users] (0x0040):
Failed to store user 0. Ignoring.
I tried with both the AD and LDAP providers but get the same error. I'm
mostly using the defaults in the domains section of sssd.conf. Snippet
below:
[domain/test]
id_provider = ad
access_provider = ad
ad_server = example.test.abcd.com
ad_domain = test.abcd.com
ldap_id_mapping = true
dyndns_update = false
krb5_keytab = /etc/sssd/abcd.keytab
ldap_schema = ad
ldap_idmap_default_domain = test.abcd.com
Would appreciate if you could provide some guidance here. Do I have to
tweak the idmap ranges with v1.11.7? The RIDs in my AD forest are in the
200k to 3000k range.
Best Regards,
Prajwal Kumar
9 years, 6 months
AD group memberships missing in sssd 1.12.0 (but showing okay in 1.9.6)
by Joschi Brauchle
With sssd-ad 1.12.0 we have the problem that all additional group
memberships of a user are missing:
-------------
# id ga57joh
uid=3298478(ga57joh) gid=3000000(tu00000gv-0defprim)
groups=3000000(tu00000gv-0defprim)
-------------
Only the main groups shows, all additional groups like
3394681(tueilntgv-0all),3393702(tueilntgv-0staff) are missing.
We have the following /etc/sssd/sssd.conf:
-------------
[sssd]
config_file_version = 2
services = nss,pam
domains = default
[nss]
filter_groups = root
filter_users = root
[pam]
[domain/default]
id_provider = ad
auth_provider = ad
access_provider = simple
chpass_provider = ad
ad_domain = ads.mwn.de
#ad_enable_gc = False <-- even this does not help!
# Disable sssd-ad ID mapping, as we want to use posix data from AD
ldap_id_mapping = False
# Disable user enumeration for speed
enumerate = False
# Set base DNs and scope for faster search
ldap_search_base = DC=ads,DC=mwn,DC=de
ldap_user_search_base = ou=Users,OU=TU,OU=IAM,DC=ads,DC=mwn,DC=de
ldap_group_search_base = ou=Groups,OU=TU,OU=IAM,DC=ads,DC=mwn,DC=de
-------------
Using sssd-ad 1.9.6, we get all groups successfully with the identical
config!
We see the following message in /var/log/sssd/sssd_default.log:
-------------
[sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call
[sdap_get_initgr_user] (0x4000): Process user's groups
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x1000): Processing
membership SID [S-1-5-32-545]
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x0080): Domain not found
for SID S-1-5-32-545
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x1000): Processing
membership SID [S-1-5-21-1499261727-55176102-3529509929-420311]
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x0400): Missing SID
S-1-5-21-1499261727-55176102-3529509929-420311 will be downloaded
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x1000): Processing
membership SID [S-1-5-21-1499261727-55176102-3529509929-571]
[sdap_ad_tokengroups_initgr_posix_tg_done] (0x0400): Missing SID
S-1-5-21-1499261727-55176102-3529509929-571 will be downloaded
...
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for
[ne96soh]
[sdap_get_groups_next_base] (0x0400): Searching for groups with base
[ou=Groups,OU=TU,OU=IAM,DC=ads,DC=mwn,DC=de]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(objectSID=S-1-5-21-1499261727-55176102-3529509929-420311)(objectclass=group)(name=*))][ou=Groups,OU=TU,OU=IAM,DC=ads,DC=mwn,DC=de].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [groupType]
[sdap_get_groups_process] (0x0400): Search for groups, returned 0 results.
[sdap_get_initgr_done] (0x4000): Initgroups done
-------------
It looks like all the missing user groups are mentioned in the "Missing
SID ... will be downloaded" messages, but are still missing in the end!
Any ideas?
Best regards,
Joschi
--
Dipl.-Ing. Joschi Brauchle, M.S.
Institute for Communications Engineering (LNT)
Technische Universitaet Muenchen (TUM)
80290 Munich, Germany
Tel (work): +49 89 289-23474
Fax (work): +49 89 289-23490
E-mail: joschi.brauchle(a)tum.de
Web: http://www.lnt.ei.tum.de/
9 years, 6 months
sssd, ldap, huge server load
by François Dagorn
Hello All,
I'm experiencing ldap servers load problems when using Fedora 20 with sssd/ldap
to authenticate users. Last year we were using Fedora 18 with sssd/ldap too, our
sssd config remains unchanged. So, what is happenning :
- sssd is always searching for users in the ldap directory. Seems that the cache
is always considered as empty or to be rebuild
Seems to retrieve all users (30 000 inside !) when the systems boots, when a user get
logged and also when a user logoff ! As a bonus, sssd load the cpu as follows
27937 root 20 0 245308 22892 21888 S *16,0* 0,3 0:09.81 sssd_nss
27935 root 20 0 245908 8296 6804 R *11,6 * 0,1 0:07.86 sssd_be
Attached the log file with debug=9 and also our sssd.conf.
Any help would be appreciated.
--
François
9 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.
9 years, 6 months
Use SSSD as a 'proxy'
by Eric VS
Hi all,
I'm new to this list and to SSSD. I just set up SSSD so that our admins can
authenticate on Linux using their Active Directory username. For this I
have a centralized 'box' (AUTH01) in the production environment. Everything
works on that single box authenticating to the AD. My question now is if
there's a way to have other Linux VMs (CentOS 6.5) in that environment
authenticate against that AUTH01 instance using only SSSD? Or do I need
something on top of it?
Sorry if this is a question that's already been asked but I've been
searching the internet without any luck yet.
Kind regards,
*Eric *
*E-mail: vs.eric(a)gmail.com <vs.eric(a)gmail.com>*
9 years, 6 months
