sssd-users January 2016

sssd-users@lists.fedorahosted.org

28 participants
30 discussions

speeding up iterative enumeration?
by James Ralston 26 Jan '16

26 Jan '16

We are using the ad provider for sssd, with the id mapping feature enabled. We have a program that obtains a list of all Active Directory users and groups via LDAP, and then calls getpwnam()/getgrnam() on those users and groups. (We used to accomplish this enumeration simply by enabling enumeration within sssd. But the performance issues this created for sssd, combined with the threat of the removal of the enumeration feature, made us search for a different solution.) Here's the problem: unless the user/group objects already happen to be in sssd's cache, enumerating the passwd/group entries in this way is very slow: 3-5 entries per second, at best. For a larger AD domain, the program can take 10-15 minutes to perform this iterative enumeration, which is much longer than we'd prefer. Can anyone think of a way to make this iterative enumeration go faster? One thing we're considering is having our program synthesize the passwd and group entries itself, rather than having sssd do it via getpwnam()/getgrnam() calls. We'll still have to look up at least one entry (to determine the slice starting point for the ID mapping), but since we can obtain each object's RID from AD, once we know the starting offset, we can calculate the uid/gid values. After that, all we need to do is synthesize the rest of the fields from the object's AD properties, the same as sssd. Thoughts? Is there a way to accelerate iterative enumeration, or should we just give up and replicate the logic sssd uses to generate passwd/group entries?

2 1

Help debugging sssd-sudo with Samba4
by Juan Asensio Sánchez 25 Jan '16

25 Jan '16

Hi I an trying to get sudo with sssd work with Samba4 provider, but I can't. I have joined the domain using realmd: realm --client-software=sssd join mmdd.indra.es After that, I have modified some sssd settings, to add sudo service, enable enumerate (during debigging), etc.: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [sssd] domains = xxxx.yyyy.es config_file_version = 2 services = nss, pam, sudo, ssh [sudo] [ssh] [domain/xxxx.yyyy.es] enumerate = True ad_domain = xxxx.yyyy.es krb5_realm = XXXX.YYYY.ES realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad case_sensitive = false ldap_user_ssh_public_key = sshPublicKey sudo_provider = ldap ldap_sudo_search_base = OU=SUDOers,DC=xxxx,DC=yyyy,DC=es ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Enabled and restarted sssd, oddjob. Now I see users and group using getent, and I can login to the client using SSH. Then, added to Samba4 the OU=SUDOers tree: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ dn: OU=SUDOers,DC=xxxx,DC=yyyy,DC=es objectClass: organizationalUnit objectClass: top ou: SUDOers name: SUDOers dn: CN=wheel,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es objectClass: sudoRole objectClass: top cn: wheel name: wheel sudoCommand: ALL sudoHost: ALL sudoUser: %wheel dn: CN=root,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es objectClass: sudoRole objectClass: top cn: root name: root sudoCommand: ALL sudoHost: ALL sudoUser: root dn: CN=sysadm,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es objectClass: sudoRole objectClass: top cn: sysadm name: sysadm sudoCommand: ALL sudoHost: ALL sudoUser: %sysadm dn: CN=defaults,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es objectClass: sudoRole objectClass: top cn: defaults description: Default sudoOptions go here distinguishedName: CN=defaults,OU=SUDOers,DC=xxxx,DC=yyyy,DC=es name: defaults sudoOption: env_keep+=SSH_AUTH_SOCK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have a user that is member of the sysadm group (I show only relevant information): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ dn: CN=My Full Name,OU=Usuarios,DC=xxxx,DC=yyyy,DC=es objectClass: posixAccount sAMAccountName: jasensios gidNumber: 10004 loginShell: /bin/bash memberOf: CN=sysadm,OU=Grupos,DC=mmdd,DC=indra,DC=es msSFU30Name: jasensios msSFU30NisDomain: xxxx msSFU30PosixMemberOf: CN=sysadm,OU=Grupos,DC=xxxx,DC=yyyy,DC=es uid: jasensios uidNumber: 10000 unixHomeDirectory: /home/jasensios dn: CN=sysadm,OU=Grupos,DC=xxxx,DC=yyyy,DC=es objectClass: posixGroup cn: sysadm sAMAccountName: sysadm gidNumber: 10014 member: memberUid: jasensios msSFU30Name: sysadm msSFU30NisDomain: xxxx msSFU30PosixMember: CN=My Full Name,OU=Usuarios,DC=xxxx,DC=yyyy,DC=es name: sysadm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ After loging with user in the client: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [jasensios@client01 ~]$ id uid=10000(jasensios) gid=10004(domain users) grupos=10004(domain users),10005(sysadm_pro),10014(sysadm) [jasensios@client01 ~]$ groups domain users sysadm [jasensios@client01 ~]$ getent passwd jasensios jasensios:*:10000:10004:My Full Name:/home/jasensios:/bin/bash ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But.... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [jasensios@client01 ~]$ sudo -l [sudo] password for jasensios: User jasensios is not allowed to run sudo on client01. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Any advice?

2 2

SSSD issue after upgrade in fedora 23 x64
by Edouard Guigné 25 Jan '16

25 Jan '16

Hello sssd users, I configured several fedora 22 x64 workstation with success with sssd against a AD domain. I followed the tutorial at https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server ("Joining the Linux client to the AD domain manually" part). Last week, I upgrraded my workstation from fedora 22 to fedora 23 x64 (using fedup). I did not change the sssd.conf, krb5.conf and krb5.keytab from fedora 22 to 23. In all upgraded fedora 23 workstations, users cannot loging anymore. Here is the error i get : sshd[9313]: pam_sss(sshd:account): Access denied for user xxxxx: 4 (System error) sshd[9313]: Failed password for xxxxx from x.x.x.x port 49459 ssh2 audit[9313]: USER_ACCT pid=9313 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=? acct="xxxxx" exe="/usr/sbin/sshd" hostname=x.x.x.x addr=x.x.x.x terminal=ssh res=failed' sshd[9313]: fatal: Access denied for user xxxxx by PAM account configuration [preauth] ... Although, users can still loging in fedora 22 workstations. Is it a known issue ? May you help me to resolve it ? Best Regards, Ed

4 19

User_attribute option
by Longina Przybyszewska 24 Jan '16

24 Jan '16

Hi, I would like to retrieve additional attribute from user object in AD , 'homeDirectory', which contains string pointing to windows share path on a samba server . The option 'user_attribute' allows that setup in [nss] section together with ' ifp' service. [sssd] services = ..,nss,ifp [nss] user_attribute = +homeDirectory I can't figure out how this extra attribute is mapped by SSSD; I would like map it to environment variable per user at login, or in any other usable way. Any hints? Thanks in advance. Best, longina

2 3

Only members of one AD group should have access to Linux login
by Hans Schou 21 Jan '16

21 Jan '16

Hi I have several users in my AD. All of them can now login with ssh to the Linux server which is not intended. In the AD I have the group MyTestGrp. I want only users in that group to have access to this server. Testing on the Linux server provides the information necessary ("admjoin" should not have access): avgjoe@host007:~$ getent passwd admjoin admjoin:*:1905540256:1905400513:AdmJoin:/home/corp.acme.com/admjoin:/bin/ba… avgjoe@host007:~$ getent group MyTestGrp MyTestGrp:*:1905738908:avgjoe,bob Where should I add MyTestGrp in the configuration files? I have looked around in /etc/sssd/ and /etc/pam.d/ without success. It is working now with sudo for the group members so I guess it should be possible. best regards

3 4

sssd net rpc rights SeDiskOperatorPrivilege
by Henry McLaughlin 20 Jan '16

20 Jan '16

I have sssd configured and working with my domain member server and I now wish to grant the SeDiskOperatorPrivilege to the "MYDOMAIN\Domain Admins" group. When I execute the command it appears to disregard the domain name and grant the privileges to the group "Unix Group\domain admins" net rpc rights list accounts -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: ... Unix Group\domain admins No privileges assigned net rpc rights grant 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: Successfully granted rights. net rpc rights list accounts -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: ... Unix Group\domain admins SeDiskOperatorPrivilege net rpc rights revoke 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: Successfully revoked rights. net rpc rights list accounts -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: ... Unix Group\domain admins No privileges assigned Below I have completely removed the domain name from the command and still get the same outcome. net rpc rights grant 'Domain Admins' SeDiskOperatorPrivilege -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: Successfully granted rights. net rpc rights list accounts -U'MYDOMAIN\administrator' Enter MYDOMAIN\administrator's password: ... Unix Group\domain admins SeDiskOperatorPrivilege

5 6

Could not convert objectSID [...] to a UNIX ID
by Hans Schou 20 Jan '16

20 Jan '16

Hi I have two users in the AD. Only one of them can login with ssh or su on the Linux server. The user admjoin is the one made the "realm join" and he can login: /var/log/sssd/sssd_corp.acme.com.log: Mapping user [AdmJoin] objectSID [S-1-5-21-2031436270-1094658265-1854952973-140256] to unix ID Adding original memberOf attributes to [AdmJoin]. And avgjoe can not login: Mapping user [AvgJoe] objectSID [S-1-5-21-2031436270-1094658265-1854952973-340002] to unix ID Could not convert objectSID [S-1-5-21-2031436270-1094658265-1854952973-340002] to a UNIX ID Why can user avgjoe not log in? (and why are the ObjectSID the same (if relevant)?) Note that when doing a "su - avgjoe" the AD converts it to AvgJoe in log-file, as defined on the AD-server. I guess there is around 20000 users defined in the AD. User AdmJoin was created when the system was setup, and user AvgJoe is added recently (he might have a very high numeric id). [sssd] domains = corp.acme.com config_file_version = 2 services = nss, pam, ssh, sudo debug_level = 7 [domain/corp.acme.com] ad_domain = corp.acme.com krb5_realm = CORP.ACME.COM realmd_tags = manages-system joined-with-samba #cache_credentials = True cache_credentials = False id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%d/%u access_provider = ad debug_level = 7 ldap_idmap_range_min = 200000 ldap_idmap_range_max = 2000200000 ldap_idmap_range_size = 200000 Any help is much appreciated. best regards Hans

2 3

Re: localauth plugin and some other questions (+ attch.)
by Longina Przybyszewska 18 Jan '16

18 Jan '16

This time with attachments ;-) HI, Sorry for delay... In attachements sssd_nss.log and sssd_a.c.realm.log Login with UPN (mail name) does not work here: root@adm-lnx438:/tmp# getent passwd user1@realm user1@n.c.realm@a.c.realm:*:10002:30000000:XXXXX XXXXX:/home/user1:/bin/bash my sssd.conf: [nss] debug_level = 9 filter_groups = root filter_users = root [sssd] debug_level = 9 domains = a.c.realm config_file_version = 2 services = nss,pam,ssh [pam] pam_verbosity = 3 debug_level = 9 [domain/a.c.realm] debug_level = 9 ad_domain = a.c.realm ad_site = SITE ad_hostname = adm-lnx438.a.c.realm id_provider = ad access_provider = ad auth_provider = ad chpass_provider = ad dyndns_update = true dyndns_update_ptr = false krb5_realm = A.C.REALM krb5_use_fast = try krb5_lifetime = 10h krb5_renewable_lifetime = 7d krb5_renew_interval = 1h krb5_confd_path = /var/lib/sss/pubconf/krb5.include.d ### use_fully_qualified_names = true ldap_id_mapping = false ldap_use_tokengroup = false ad_gpo_access_control = disabled best, Longina > -----Oprindelig meddelelse----- > Fra: Longina Przybyszewska [mailto:longina@sdu.dk] > Sendt: 11. januar 2016 16:25 > Til: End-user discussions about the System Security Services Daemon > Emne: [SSSD-users] Re: localauth plugin and some other questions > > > > > -----Oprindelig meddelelse----- > > Fra: Sumit Bose [mailto:sbose@redhat.com] > > Sendt: 8. januar 2016 11:23 > > Til: End-user discussions about the System Security Services Daemon > > Emne: [SSSD-users] Re: localauth plugin and some other questions > > > > On Wed, Jan 06, 2016 at 01:11:50PM +0000, Longina Przybyszewska wrote: > > > > > > Thank you for the answers. > > > There are still some issues: > > > > > > > > > > > 2. > > > > > I tried login with setup for UPN/sAMAccountName login- without > > success. > > > > > Is login with cross realm's UPN or short sAMAccoutName supported > in > > this > > > > sssd version? > > > > > > > > > > In database for default domain cache_a.c.realm.db user object > > > > > has > > > > following names (for 'use_fully_qualified_names = true' setup): > > > > > > > > > > dn: name = user1(a)n.c.realm ... > > > > > name: user1(a)n.c.realm > > > > > nameAlias. user1(a)n.c.realm > > > > > UserPrincipalName: user1@REALM > > > > > canonicalUserPrincipalName: user1(a)N.C.REALM > > > > > > > > The plain sAMAccoutName 'user1' will not work because > > > > use_fully_qualified_names = true. What should work is 'DOM\user1' > > > > where DOM is the NetBIOS domain name of n.c.realm domain. > > > > Additionally I would expect that user1@REALM should work. > > > > > > > > > > Right. user1(a)n.c.realm and DOM\user1 login works. > > > > > > Login as user1@REALM (and user1@realm) does not work. > > > > hm, that's odd, can you send me the logs when trying to login with > > user1@REALM? > > > > > > > > getent passwd user1@realm > > > user1@n.c.realm@a.c.realm:*:10002:30000000::/home/user1:/bin/bash > > > > 'user1@n.c.realm@a.c.realm' looks odd, do you map the user name to an > > attribute other than sAMAccoutName? > > > > I use " id_provider = ad" and do not map specifically user name to any > attribute.. > > Attributes in AD: > uid = user1 > userPrincipalName = user1@realm > sAMAccountName = user1 > > SSSD defaults: > ldap_user_name = uid > ldap_user_principal = krbPrincipalName > > krb5_use_enterprise_principal = true > > There is no krbPrincipalName attribute in user object in AD . > > Sssd.conf: > > > [nss] > debug_level = 9 > filter_groups = root > filter_users = root > > [sssd] > debug_level = 9 > > domains = a.c.realm > config_file_version = 2 > services = nss, pam,ssh > > [pam] > pam_verbosity = 3 > debug_level = 9 > > [domain/a.c.realm] > debug_level = 9 > > ldap_use_tokengroup = false > dyndns_update = true > dyndns_update_ptr = true > > id_provider = ad > access_provider = ad > auth_provider = ad > chpass_provider = ad > > krb5_realm = A.C.REALM > krb5_use_fast = try > krb5_confd_path = /var/lib/sss/pubconf/krb5.include.d > > ad_domain = a.c.realm > ad_site = SITE > ad_hostname = adm-lnx438.a.c.realm > > use_fully_qualified_names = true > ldap_id_mapping = false > > > > > > > > > The best would be able to login with sAMAccountName; The next best > > > with upn, then with fqdn. > > > > > > I tried without success the following setup for login with short names : > > > [nss] > > > subdomain_inherit = ldap_user_principal > > > > > > [domain/a.c.realm] > > > .. > > > ldap_user_principal = sAMAccountName > > > > this won't work because ldap_user_principal value is used as a > > Kerberos principal without further processing. > > > > You might want to try the 'default_domain_suffix' option, see man > > sssd.conf for details. > > > Manual says, that 'default_domain_suffix' is usable if all users are located in > trusted domain while computer's are in primary domain. > With this option, users can login with short names. > Our users are in several trusted domains; what should be the value of > 'default_domain_suffix' ? > > > > > > >

1 0

localauth plugin and some other questions
by Longina Przybyszewska 18 Jan '16

18 Jan '16

Hi, I did some testing of sssd-13.2 version in Ubuntu-16.04 (ldap_idmapping = false) Login with fqdn in cross realm and Kerberos NFS automount seems to work almost out-of-the-box. This is great. I have still some questions: In my setup, I have configured only for one domain - the domain where I join machine. SRV discovery can figure out all domains and figure out AD structure; 1. Is it still necessary make an explicit list of all domains in the 'domains' statement? [sssd] .. domains = a.c.realm, n.c.realm, s.c.realm, c.realm ... 2. I tried login with setup for UPN/sAMAccountName login- without success. Is login with cross realm's UPN or short sAMAccoutName supported in this sssd version? In database for default domain cache_a.c.realm.db user object has following names (for 'use_fully_qualified_names = true' setup): dn: name = user1(a)n.c.realm ... name: user1(a)n.c.realm nameAlias. user1(a)n.c.realm UserPrincipalName: user1@REALM canonicalUserPrincipalName: user1(a)N.C.REALM 3. Localauth plugin: the option : krb5_confd_path = /var/lib/sss/pubconf/krb5.conf.d -does not create that directory (I understand from the doc that sssd should take care about it); However after manually creating this directory I can see many fails in log: [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0200): Mapping file for domain [a.c.realm] is [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realm] [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0040): creating the temp file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4PYcJ] for domain-realm mappings failed. [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0080): Could not remove file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4P<B0>]: [2]: No such file or directory .... ls -ld drwxr-xr-x 2 root root 4096 Dec 16 16:08 /var/lib/sss/pubconf/krb5.conf.d/ Default value for option 'krb5_canonicalize' is FALSE; I set 'canonicalize' to 'true' in krb5.conf - is it enough? I understand from docs localauth plugin needs it. 4. ldbsearch Can I somehow (I do not think about log with high debug level) see all configured and default options for SSSD? Best, Longina

3 7

Disabling SSSD Discovery Service
by Eric Aiken 15 Jan '16

15 Jan '16

I’ve been beating my head over this. After upgrading RHEL5 systems to RHEL6, the kerberos/ldap services quit working correctly. I’ve resolved most of the issues. I also embraced SSSD. My remaining challenge is to disable the SSSD Discovery service. Authentication and authorization works, it’s just DNS round-robins DC’s that are not reachable and this ultimately causes failures (and latency) In short I need to hard code who the client talks to. Inevitably I keep finding the client doing a DNS lookup for domaindnszones.<domain>. Due to limitations in MS windows DNS, This returns IP’s for DC’s in VLANs not accessible to certain subnets. Round-Robin DNS with subnet masking doesn’t work for clients that are not AD CSE capable. (eg AD client side extension). Even if I could get the net masking to work, I don’t believe it would work for our IP space as the necessary netmask would need to be a class A , thereby getting all the DC’s again. For the record AD (and our IP subnets) are configured properly for sites and services. I’ve tried lots of variations and configurations of: hardcoding: kdc = admin_server = krb5_backup-server = dns_lookup_realm = false dns_lookup_dc = false ldap_uri ldap_backup_uri I tried working with sssd-ad as it allows you to define ad_server and ad_enable_dns_sites. Again the sssd discovery service continues to try and “control” where to look. From my research I’m not alone, there are others with similar challenges, but I’ve yet to find someone with an “old-school” configuration. Is there a way to tell sssd use “ these and only these” DC’s for Kerberos and LDAP on a client? I’ll manage HA and load balancing. Thanks for your thought and advise. • Respectons ensemble l'environnement. N'imprimez ce message que si nécessaire. Let's respect the environment together. Only print this message if necessary.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2016