sssd-users September 2018

sssd-users@lists.fedorahosted.org

19 participants
18 discussions

Re: override_gid not changing default GID
by Jakub Hrozek 17 Sep '18

17 Sep '18

> On 14 Sep 2018, at 00:25, Kevin Murakoshi <ksmurakoshi(a)UCDAVIS.EDU> wrote: > > Hi All, > > I'm relatively new to SSSD, and this has me stumped. I'm trying to override the default GID for all the users on a OEL 7 system. I set override_gid = 100 in sssd.conf, but as far as i can tell nothing's happening. Looking into the sssd cache, I see: > > dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb > createTimestamp: 1536876547 > fullName: riceboy > gecos: riceboy > gidNumber: 846575921 > name: riceboy(a)ad3.ucdavis.edu > objectCategory: user > uidNumber: 190295 > > When I set auto_private_groups = true, the GID does change: > > dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb > createTimestamp: 1536877117 > fullName: riceboy > gecos: riceboy > gidNumber: 190295 > name: riceboy(a)ad3.ucdavis.edu > objectCategory: user > uidNumber: 190295 I think this is a bug. Looking at the domain the user comes from and the domain defined in sssd.conf, this user comes from a trusted domain, correct? The domain defined in sssd.conf is ou.ad3.ucdavis.edu, but the domain the user comes from is ad3.ucdavis.edu I could reproduce this in my local test, it seems that the override_gid option is not applied to subdomain users. E.g, using override_gid=55555 I can see the administrator user from the joined domain to have their gid overriden: $ id administrator(a)win.trust.test uid=1323800500(administrator(a)win.trust.test) gid=55555 groups=55555,1323800572(denied rodc password replication group(a)win.trust.test),1323800520(group policy creator owners(a)win.trust.test),1323800513(domain users(a)win.trust.test),1323800512(domain admins(a)win.trust.test),1323800519(enterprise admins(a)win.trust.test),1323800518(schema admins(a)win.trust.test) But not the user from a trusted domain: $ id administrator(a)child.win.trust.test uid=52600500(administrator(a)CHILD.win.trust.test) gid=52600500(administrator(a)CHILD.win.trust.test) groups=52600500(administrator(a)CHILD.win.trust.test),52600513 Does override_gid work for you for users from the joined domain at least? > > Another data point (not sure if this is related), when I try and override the GID on an existing group, the name will change, but the GID will not. (original GID of "Domain Users" is 846575921) > [root@tcsnd2 ~]# sss_override group-add "Domain Users(a)ad3.ucdavis.edu" -n NewName -g 1234567 > SSSD needs to be restarted for the changes to take effect. > [root@tcsnd2 ~]# systemctl restart sssd > [root@tcsnd2 ~]# id riceboy(a)ad3.ucdavis.edu > uid=190295(riceboy) gid=846575921(newname) groups=846575921(newname),1170(status),1061419070(ism-us-systems),1061419998(iet-us-banner),1061419025(ism-us-status),1061419997(iet-us-edrs),1061419993(iet-us- > rbds),1061419045(ism-us-ism),1234567(newname),1061419999(iet-us-ansible),1061419046(ism-us-isun-susers),1061419058(ism-us-netbackup),1061419074(ism-us-zenoss) > > Hmm, this sounds like a bug as well. Does it work with any of the non-primary groups at least? > I'm sure there's something simple I'm missing, any ideas? > > > > > My sssd.conf file > > [nss] > filter_groups = root > filter_users = root > reconnection_retries = 3 > debug_level = 2 > > [pam] > reconnection_retries = 3 > debug_level = 2 > > [sssd] > domains = ou.ad3.ucdavis.edu > config_file_version = 2 > services = nss, pam, ifp > debug_level = 2 > > default_domain_suffix = AD3.UCDAVIS.EDU > > [domain/ou.ad3.ucdavis.edu] > ad_domain = ou.ad3.ucdavis.edu > krb5_realm = OU.AD3.UCDAVIS.EDU > krb5_auth_timeout = 30 > debug_level = 4 > override_gid = 100 > > > cache_credentials = True > > id_provider = ad > auth_provider = ad > chpass_provider = ad > access_provider = ad > #ad_access_filter = (memberOf=CN=IET-US-Unit-PS,OU=US-byOrg,OU=Groups,OU=IET-New,OU=DEPARTMENTS,DC=ou,DC=ad3,DC=ucdavis,DC=edu) > > use_fully_qualified_names = True > > ;;; Must be false for UNIX UIDs to be retrieved from AD3 > ldap_id_mapping = false > ldap_schema = ad > > krb5_store_password_if_offline = True > > default_shell = /bin/bash > override_homedir = /home/%u > fallback_homedir = /tmp/ > override_shell = /bin/ksh > #auto_private_groups = true > > access_provider = simple > simple_allow_groups = ISM-US-ISM(a)ou.ad3.ucdavis.edu, IET-US-BANNER(a)ou.ad3.ucdavis.edu > > ignore_group_members = TRUE > ldap_use_tokengroups = True > ldap_group_nesting_level = 0 > ldap_groups_use_matching_rule_in_chain = True > ldap_initgroups_use_matching_rule_in_chain = True > full_name_format = %1$s > dyndns_update = false > ~ > > Kevin Murakoshi > IET Enterprise Student Applications > > ksmurakoshi(a)ucdavis.edu > > (530) 752-0318 (office) > (530) 219-8188 (cell) > > > > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…

1 0

override_gid not changing default GID
by Kevin Murakoshi 13 Sep '18

13 Sep '18

Hi All, I'm relatively new to SSSD, and this has me stumped. I'm trying to override the default GID for all the users on a OEL 7 system. I set override_gid = 100 in sssd.conf, but as far as i can tell nothing's happening. Looking into the sssd cache, I see: dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb createTimestamp: 1536876547 fullName: riceboy gecos: riceboy gidNumber: 846575921 name: riceboy(a)ad3.ucdavis.edu objectCategory: user uidNumber: 190295 When I set auto_private_groups = true, the GID does change: dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb createTimestamp: 1536877117 fullName: riceboy gecos: riceboy gidNumber: 190295 name: riceboy(a)ad3.ucdavis.edu objectCategory: user uidNumber: 190295 Another data point (not sure if this is related), when I try and override the GID on an existing group, the name will change, but the GID will not. (original GID of "Domain Users" is 846575921) [root@tcsnd2 ~]# sss_override group-add "Domain Users(a)ad3.ucdavis.edu" -n NewName -g 1234567 SSSD needs to be restarted for the changes to take effect. [root@tcsnd2 ~]# systemctl restart sssd [root@tcsnd2 ~]# id riceboy(a)ad3.ucdavis.edu uid=190295(riceboy) gid=846575921(newname) groups=846575921(newname),1170(status),1061419070(ism-us-systems),1061419998(iet-us-banner),1061419025(ism-us-status),1061419997(iet-us-edrs),1061419993(iet-us- rbds),1061419045(ism-us-ism),1234567(newname),1061419999(iet-us-ansible),1061419046(ism-us-isun-susers),1061419058(ism-us-netbackup),1061419074(ism-us-zenoss) I'm sure there's something simple I'm missing, any ideas? My sssd.conf file [nss] filter_groups = root filter_users = root reconnection_retries = 3 debug_level = 2 [pam] reconnection_retries = 3 debug_level = 2 [sssd] domains = ou.ad3.ucdavis.edu config_file_version = 2 services = nss, pam, ifp debug_level = 2 default_domain_suffix = AD3.UCDAVIS.EDU [domain/ou.ad3.ucdavis.edu] ad_domain = ou.ad3.ucdavis.edu krb5_realm = OU.AD3.UCDAVIS.EDU krb5_auth_timeout = 30 debug_level = 4 override_gid = 100 cache_credentials = True id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad #ad_access_filter = (memberOf=CN=IET-US-Unit-PS,OU=US-byOrg,OU=Groups,OU=IET-New,OU=DEPARTMENTS,DC=ou,DC=ad3,DC=ucdavis,DC=edu) use_fully_qualified_names = True ;;; Must be false for UNIX UIDs to be retrieved from AD3 ldap_id_mapping = false ldap_schema = ad krb5_store_password_if_offline = True default_shell = /bin/bash override_homedir = /home/%u fallback_homedir = /tmp/ override_shell = /bin/ksh #auto_private_groups = true access_provider = simple simple_allow_groups = ISM-US-ISM(a)ou.ad3.ucdavis.edu, IET-US-BANNER(a)ou.ad3.ucdavis.edu ignore_group_members = TRUE ldap_use_tokengroups = True ldap_group_nesting_level = 0 ldap_groups_use_matching_rule_in_chain = True ldap_initgroups_use_matching_rule_in_chain = True full_name_format = %1$s dyndns_update = false ~ Kevin Murakoshi IET Enterprise Student Applications ksmurakoshi(a)ucdavis.edu (530) 752-0318 (office) (530) 219-8188 (cell)

1 0

Signature for recent downloads
by Jan Engelhardt 10 Sep '18

10 Sep '18

sssd-1.16.3 and sssd-2.0.0 were signed with a new key that has not been published on the standard keyservers. Can you do that? 15:30 a4:../ldap/sssd > gpg --verify sssd-2.0.0.tar.gz.asc gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf gpg: keyserver option 'no-try-dns-srv' is unknown gpg: assuming signed data in 'sssd-2.0.0.tar.gz' gpg: Signature made 2018-08-13T21:37:45 CEST gpg: using RSA key 0x70C146062250BDFA gpg: Can't check signature: No public key 15:30 a4:../ldap/sssd > gpg --recv-keys 0x70C146062250BDFA gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf gpg: keyserver option 'no-try-dns-srv' is unknown gpg: keyserver receive failed: No data

2 1

Concerning "ldap_idmap_default_domain_sid", "[domain/default]", and "ldap_idmap_default_domain"
by Lawrence Kearney 05 Sep '18

05 Sep '18

I beleive I understand the use of the the "ldap_idmap_default_domain_sid" directive. Most simply the MURMUR algorithm will be disabled and the domain configuration designated as the "default" domain will be assigned to slice [0]. My observation is that the UID-GID for an object becomes (ldap_idmap_range_min + <object_RID>) in this configuration. The man pages are less clear on why and how specifying which domain is the default in a multi-domain configuration matters. My assumption is that the sole purpose of the "[domain/default]" and "ldap_idmap_default_domain" options is to do just that. "[domain/default]" - Is the entended use for this domain stanza header? - Is is still a valid configuration choice? "ldap_idmap_default_domain" - Is the entended use for this configuration directive? - If it is specified in one domain stanza in a multi-domain configuration will the configuration be honored across other configured domains? Many thanks as always, -- lawrence

2 2

ldap slices in sssd.conf
by Chris Kowalczyk 05 Sep '18

05 Sep '18

Hello All, I have a question regarding ldap slices defined in sssd configuration. Is it fine to have just one group defined by ldap_idmap_range_min, ldap_idmap_range_max and ldap_idmap_range_size parameters? So, something like: ldap_idmap_range_min = 200000 ldap_idmap_range_max = 3000200000 ldap_idmap_range_size = 3000000000 Would it be a correct configuration, providing there is only one domain? Also, what are the requirements for max_id, etc parameters? I found that max_id should be bigger than ldap_idmap_range_max etc, but are there any limits for it or any other restrictions (max value etc)? Regards, Chris Kowalczyk

3 3

Looking for SSSD/AD consultant
by Bastian Rosner 05 Sep '18

05 Sep '18

Hi, We are looking for a consultant to help us integrating SSSD on Debian in a multi-domain Windows Active Directory (no IPA) infrastructure. In case you are interested, feel free to contact me directly. Regards, Bastian

1 0

sssd.conf sections only work if they reflect existing AD domain, why?
by Daniele Raffo 03 Sep '18

03 Sep '18

Hello, I'm trying to define two sssd groups in order to assign a different login shell to AD users belonging to two different AD groups in our domain FOOBAR.GLOBAL. However, all users are unable to login and get an error "Authentication failed". If I change a sssd section to [domain/FOOBAR.GLOBAL] so to reflect the existing AD domain, users defined in that sssd group are able to login. However, clearly in this way I cannot define more than one section. Why is that? How to define sssd sections with names different than the existing AD domain? Thanks in advance. Below is my sssd.conf. [sssd] domains = FOOBAR_ADMINS.GLOBAL,FOOBAR_NOLOGIN.GLOBAL config_file_version = 2 services = nss, pam [domain/FOOBAR_NOLOGIN.GLOBAL] ldap_user_search_filter = (memberOf=CN=Simple Users,OU=Security Groups,DC=FOOBAR,DC=GLOBAL) default_shell = /bin/sh ad_server = ad01.foobar.global ad_domain = FOOBAR.GLOBAL krb5_realm = FOOBAR.GLOBAL realmd_tags = manages-system joined-with-adcli cache_credentials = False id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = Simple Users(a)FOOBAR.GLOBAL [domain/FOOBAR_ADMINS.GLOBAL] ldap_user_search_filter = (memberOf=CN=Administrators,OU=Security Groups,DC=FOOBAR,DC=GLOBAL) default_shell = /bin/bash ad_server = ad01.foobar.global ad_domain = FOOBAR.GLOBAL krb5_realm = FOOBAR.GLOBAL realmd_tags = manages-system joined-with-adcli cache_credentials = False id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = Administrators(a)FOOBAR.GLOBAL

3 5

mod_lookup_identity & Apache authorization
by Ondrej Valousek 03 Sep '18

03 Sep '18

Hi list, I would like to use something like mod_authz_unixgroups or mod_lookup_identity to allow users to browse certain location based on their group membership. I know that mod_authz_unixgroup would do exactly what I need via the "require unix-group" parameter, but unfortunately that module does not seem to be present in RedHat repo and I do not want to compile it myself. I am wondering, can mod_lookup_identity (connected to SSSD via the ifp-dbus) do something similar? Thanks, Ondrej ----- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2018