April 2019 - sssd-users - Fedora Mailing-Lists

by Harald Dunkel

Hi folks, sssd 1.16.3-1 (rebuilt for Debian 9), systemd At boot time sssd_nss fails to initialize. systemctl status sssd shows root@srvl061:~# systemctl status sssd * sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-11-22 11:57:30 CET; 46s ago Main PID: 1312 (sssd) Tasks: 5 (limit: 7372) CGroup: /system.slice/sssd.service |-1312 /usr/sbin/sssd -i --logger=files |-1345 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain example.com --uid 0 --gid 0 --logger=files |-1533 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files |-1534 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files `-1535 /usr/lib/x86_64-linux-gnu/sssd/sssd_pac --uid 0 --gid 0 --logger=files Nov 22 11:57:25 srvl061.ac.example.com systemd[1]: Starting System Security Services Daemon... Nov 22 11:57:25 srvl061.ac.example.com sssd[1312]: Starting up Nov 22 11:57:25 srvl061.ac.example.com sssd[be[1345]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1533]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1534]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1535]: Starting up Nov 22 11:57:30 srvl061.ac.example.com systemd[1]: Started System Security Services Daemon. Nov 22 11:57:45 srvl061.ac.example.com sssd[be[1345]: Backend is offline Apparently this is a problem of resolvconf generating /etc/\ resolv.conf at boot time. If I replace it by a static file, then the problem is gone. Question is, how can I tell systemd to wait for resolv.conf? Is there some timeout in the backend I could adjust? Does it wait for the network at all? Every helpful comment is highly appreciated Regards Harri

1 week, 6 days

5
7
0 / 0

Curiousity question about 'realm permit <user>'

by Spike White

All, I have sssd set up and doing cross-domain AD authentication. I'm using the simple access provider and conferring login access per group. Occasionally per user. I notice that if I do a basic 'realm permit <user>', that it adds this user to the wrong AD domain: Example: realm permit processehcprofiler adds it to my JAPN.COMPANY.COM AD domain, not my local AD domain (AMER). If I attempt to do to realm permit -R AMER.COMPANY.COM processehcprofiler(a)AMER.COMPANY.COM I get this error: realm: Couldn't find a matching realm Through various experimentation, I find that if I do this: realm permit -R amer.company.com processehcprofiler(a)amer.company.com that it works. As confirmed by 'sssctl user-checks processehcprofiler' I notice my "domain" entries in /etc/sssd/sssd.conf file are all lower case: domains = amer.company.com,apac.company.com,emea.company.com, japn.company.com ... [domain/amer.company.com] ad_domain = amer.company.com ... [domain/apac.company.com] ad_domain = apac.company.com ... [domain/emea.company.com] ad_domain = emea.company.com ... [domain/japn.company.com] ad_domain = japn.company.com ... I'm used to Kerberos where domain names are uc and account names are lc. So to do: realm permit -R AMER.COMPANY.COM processehcprofiler(a)AMER.COMPANY.COM I have to re-write all the domain names in my sssd.conf file to uc? Spike

2 weeks, 1 day

2
4
0 / 0

Is it possible to use the full username+domain name when using proxy_pam_target ?

by David Fournier

I've been tasked with adding two-factor authentication to one of our servers that will be exposed to the net. Requirements include using an existing 2FA system which uses RADIUS for authentication, and that users from both the client domain (unicorn.local) and the management domain (rainbow.local) can log in. The RADIUS server is the same for both domains. I believed I could use sssd with auth_provider = proxy and then specify my RADIUS pam module in the proxy_pam_target, however after running tests it appears that sssd only provides the username part of the fully qualified username to proxy_pam_target (i.e. if the user is 'stranger(a)rainbow.local', only 'stranger' is passed to the modules specified in proxy_pam_target). Is there a way/switch/configuration option that I would have missed that would allow passing the full username to my pam target? Content of /etc/sssd/sssd.conf ------------------------------- [sssd] domains = unicorn.local,rainbow.local config_file_version = 2 services = nss, pam full_name_format = %1$s@%2$s [domain/unicorn.local] id_provider = ldap ldap_id_mapping = True ldap_schema = AD ldap_group_nesting_level = 8 ldap_uri = ldap://pradad1001.unicorn.local ldap_search_base = dc=unicorn,dc=local ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=unicorn,DC=local ldap_default_authtok_type = password ldap_default_authtok = ************* default_shell = /bin/bash use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = L_Unicorn_SSH_Admins auth_provider = proxy proxy_pam_target = sssdauthproxy [domain/rainbow.local] id_provider = ldap ldap_id_mapping = True ldap_schema = AD ldap_group_nesting_level = 8 ldap_uri = ldap://otherad2001.rainbow.local ldap_search_base = dc=rainbow,dc=local ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=rainbow,DC=local ldap_default_authtok_type = password ldap_default_authtok = ************** default_shell = /bin/bash use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = L_Rainbow_SSH_Admins auth_provider = proxy proxy_pam_target = sssdauthproxy End Content of /etc/sssd/sssd.conf ------------------------------- Content of sssdauthproxy ------------------------------------- auth required pam_warn.so auth required pam_radius_auth.so End Content of sssdauthproxy ------------------------------------- Note that I added pam_warn.so right before pam_sss.so, the output shows the difference in users: Apr 24 17:16:58 SAclt001 sshd[15553]: pam_warn(sshd:auth): function=[pam_sm_authenticate] service=[sshd] terminal=[ssh] user=[stranger(a)rainbow.local] ruser=[<unknown>] rhost=[bbb.bbb.bbb.bb] Apr 24 17:16:58 SAclt001 proxy_child: pam_warn(sssdauthproxy:auth): function=[pam_sm_authenticate] service=[sssdauthproxy] terminal=[ssh] user=[stranger] ruser=[] rhost=[bbb.bbb.bbb.bb] Thanks for reading that far!

2 weeks, 3 days

2
2
1 / 0

password change fails for user with 'change password on next login' selected in AD

by soham chakraborty

Hi, I have the following issue. 1) I have created a new user in AD. 2) When forcing user to change password at next logon in AD, password change does not work from the Linux client. But, if I don't force the user to change password at next logon in AD, then after logging in, I can change password of the user with passwd command. Is this normal? If not, why is this happening? My sssd.conf file is: # cat /etc/sssd/sssd.conf [sssd] domains = ad.corp.org config_file_version = 2 services = nss, pam, ssh debug_level = 9 [pam] pam_pwd_expiration_warning = 7 offline_credentials_expiration = 5 debug_level = 9 [domain/ad.corp.org] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = simple ad_server = ad-server1, ad-server2, ad-server3 cache_credentials = true krb5_store_password_if_offline = true default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = false fallback_homedir = /home/%u simple_allow_groups = foo, bar, baz debug_level = 9

3 weeks

2
3
0 / 0

Re: Problems with subdomains_provider & group membership

by Jakub Hrozek

On Tue, Apr 23, 2019 at 12:03:20PM +0000, Ondrej Valousek wrote: > Hi List, > I just noticed that sssd is unable to detect any groups user belongs to after I set > Subdomains_provider = none > In my sssd.conf > > Using AD provider, using token groups, not using fully qualified names. > Is this an expected behavior? > Note I switched subdomain_provider off as otherwise sssd keeps poking around and requesting domain controllers which are not available. btw this was solved by using ad_enabled_domains=joined.domain

3 weeks, 1 day

1
0
0 / 0

sss_obfuscate and conf.d

by Mario Rossi

Hi sssd users! I am trying to encrypt a password via sss_obfuscate , but the binary refuses to work to conf.d/ folder configs root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se Enter password: Re-enter password: No such domain LDAP If I append the contents of conf.d/LDAP.conf to sssd.conf.se, it works as expected root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se Enter password: Re-enter password: root@sd7[/etc/sssd]# root@sd7[/etc/sssd]# rpm -q sssd sssd-1.16.2-13.el7_6.5.x86_64 root@sd7[/etc/sssd]# cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) Thanks

3 weeks, 1 day

3
2
0 / 0

Any way to convince realm join not to do authselect in RHEL8?

by Spike White

All, Basically here is the realm command we use to join the appropriate regional AD domain: realm join -v --automatic-id-mapping=no --computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM" --user-principal="host/`hostname --fqdn`@$JOINDOMAIN" $JOINDOMAIN As part of this, realm join internally runs the following command: * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service But that sets /etc/pam.d/password-auth and /etc/pam.d/system-auth to a sub-optimal PAM stack. I.e., not what we desire. For example, 99.9% of our users are in AD. So we want to run pam_sssd *before* pam_unix. We are very comfortable with testing and debugging PAM stacks. We have a stable, tested PAM stack that works great -- ever since RHEL7. Basically, after the 'realm join' above is done, we have to overwrite /etc/pam.d/{system-auth,password-auth,postlogin} with what we desire. If 'realm join' can't be convinced to not run authselect, we're ok with creating a custom/profile authselect profile with what we want. And then convince realm join to run: authselect select custom/profile Instead of the above authselect select sssd Prior to running 'realm join', I have to drop down a /etc/realmd.conf file so that the 'realm join' behaves as I want it to. Is there any option in realmd.conf to not run authselect or tailor the authselect command? Or may a flag on the 'realm discover' command line? I don't remember any of these problems with realm join on RHEL7. Maybe it was running authconfig inappropriately as well -- and I just never noticed, because I over-wrote with desired PAM stack? Spike

3 weeks, 3 days

3
3
0 / 0

Windows 10 Roaming Profile Issue

by Bob Smith

Hi, On Windows Server 2008 R2 Enterprise, Profiles path is \\fs\profiles\rprofile On Centos Version 7, Samba Version 4.7.1 and ROLE_DOMAIN_MEMBER I'm getting Event ID 1521 on Windows 10 PC and roaming profile is not working. I was told the roaming profile works with winbind, but I'm using sssd. My issue is that Domain Admins is unknown to the Unix OS. Does roaming profile work with sssd? Thanks! B.

3 weeks, 3 days

2
1
0 / 0

Problems with subdomains_provider & group membership

by Ondrej Valousek

Hi List, I just noticed that sssd is unable to detect any groups user belongs to after I set Subdomains_provider = none In my sssd.conf Using AD provider, using token groups, not using fully qualified names. Is this an expected behavior? Note I switched subdomain_provider off as otherwise sssd keeps poking around and requesting domain controllers which are not available. Thanks. Ondrej

1 month

1
0
0 / 0

sssd-ldap: specify source port for LDAP connections?

by Dmitry Donskih

Hello everyone, I have a terminal server with sssd-ldap setup, users authenticate to Active Directory. Now I need to restrict users' access to AD server with LDAP from their terminal sessions. My idea is to define one privileged source IP port which is used only by SSSD when connecting to AD, and block connections originating from other ports. Is it possible? Does anyone have other ideas on similar problem?

1 month

2
1
0 / 0

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2019