sssd-users May 2013

sssd-users@lists.fedorahosted.org

23 participants
20 discussions

ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder 18 Mar '15

18 Mar '15

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.

5 22

Re: [SSSD-users] Problem with sssd and udev
by John Bossert 04 Jun '13

04 Jun '13

>> On Mon, May 20, 2013 at 08:59:28PM +0000, John Bossert wrote: >> /var/log/messages suggests that udev starts before sssd: >> >> May 17 16:54:07 seadv01-db01 kernel: udev: starting version 147 >> May 17 16:54:09 seadv01-db01 sssd: Starting up > On Tue, May 21, 2013 at 09:01:53 -0700, Jakub Hrozek wrote: > I haven't found the bug Stephen was referring to (though I remember > there was one as well) but if udev needs a remote user, then it should > be starting after the SSSD. Does this suggest a different bug - that sssd should be started before udev? If so, how should it be submitted?

3 3

passwd: Authentication token manipulation error
by Harris, Bryan L. 04 Jun '13

04 Jun '13

Howdy folks, I'm having an issue with password resets which I'm sorry to say I haven't been able to figure out by google search or searching the mailing list archives. I tried to make my sssd configuration as minimal as possible following the doc on the wiki about authenticating to 2008 AD server (see [3] below) and I used the keytab method and instead of editing PAM files I ran authconfig because I'm on Red Hat. When I switch (su - bryan.harris.adm) to my AD user and run passwd, it allows me to type both old and new passwords. Right away it says "Password change failed." Then after about 2 seconds it says "passwd: Authentication token manipulation error" on a new line. I found [1] and [2] below which seem similar to my issue. I have played a bit with my PAM options, but to no avail. Can anyone tell me what I'm doing wrong? I can post the huge log messages, I just didn't want the email to get too large straight away. [1] - https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/826989 [2] - https://lists.fedorahosted.org/pipermail/sssd-users/2012-July/000041.html [3] - https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%2… RHEL 6.4 pam-1.1.1-13 sssd-1.9.2-82 --- first off here is what I added to the my.great.domain zone in BIND --- _ldap._tcp 1D IN SRV 0 100 389 dc01 _ldap._tcp 1D IN SRV 0 100 389 dc02 _kerberos._tcp 1D IN SRV 0 100 88 dc01 _kerberos._tcp 1D IN SRV 0 100 88 dc02 _kpasswd._tcp 1D IN SRV 0 100 464 dc01 _kpasswd._tcp 1D IN SRV 0 100 464 dc02 _kerberos._udp 1D IN SRV 0 100 88 dc01 _kerberos._udp 1D IN SRV 0 100 88 dc02 _kpasswd._udp 1D IN SRV 0 100 464 dc01 _kpasswd._udp 1D IN SRV 0 100 464 dc02 The rest of the files below are on linux-server. --- /etc/pam.d/system-auth --- #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so maxrepeat=3 difok=4 lcredit=-1 ocredit=-1 ucredit=-1 dcredit=-1 try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow try_first_pass remember=24 use_authtok password sufficient pam_sss.so use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so session optional pam_krb5.so --- /etc/pam.d/password-auth --- #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so maxrepeat=3 difok=4 lcredit=-1 ocredit=-1 ucredit=-1 dcredit=-1 try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok password sufficient pam_sss.so use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so session optional pam_krb5.so --- /etc/krb5.conf --- [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MY.GREAT.DOMAIN dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = yes [realms] MY.GREAT.DOMAIN = { } [domain_realm] my.great.domain = MY.GREAT.DOMAIN .my.great.domain = MY.GREAT.DOMAIN --- /etc/krb5.keytab --- # This has the keytab from the 2008 AD domain controller. --- /etc/sssd/sssd.conf --- [domain/default] cache_credentials = False krb5_realm = MY.GREAT.DOMAIN auth_provider = krb5 chpass_provider = krb5 debug_level = 9 [sssd] config_file_version = 2 domains = MY.GREAT.DOMAIN services = nss, pam debug_level = 9 [nss] filter_groups = root filter_users = root reconnection_retries = 3 debug_level = 9 [pam] reconnection_retries = 3 debug_level = 9 [domain/MY.GREAT.DOMAIN] enumerate = True cache_credentials = False id_provider = ldap access_provider = ldap ldap_access_filter = memberOf=CN=Linux Admins,OU=Security Groups,OU=Groups,OU=MYGROUP,DC=my,DC=great,DC=domain auth_provider = krb5 chpass_provider = krb5 debug_level = 9 ldap_schema = rfc2307bis ldap_force_upper_case_realm = True ldap_sasl_mech = gssapi ldap_sasl_authid = host/linux-server.my.great.domain(a)MY.GREAT.DOMAIN ldap_uri = ldap://dc01.my.great.domain/,ldap://dc02.my.great.domain ldap_user_name = sAMAccountName ldap_user_object_class = person ldap_group_object_class = group ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_modify_timestamp = whenChanged ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_user_gecos = displayName ldap_krb5_keytab = /etc/krb5.keytab ldap_krb5_ticket_lifetime = 86400 krb5_realm = MY.GREAT.DOMAIN #krb5_kpasswd = dc01.my.great.domain #krb5_server = dc01.my.great.domain,dc02.my.great.domain krb5_validate = true krb5_canonicalize = false krb5_renewable_lifetime = 7d krb5_lifetime = 24h krb5_use_fast = try --- grep -i error /var/log/secure --- May 30 08:43:26 linux-server passwd: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)] May 30 08:43:26 linux-server passwd: pam_sss(passwd:chauthtok): Password change failed for user bryan.harris.adm: 20 (Authentication token manipulation error --- /var/log/sss/* --- I am not sure what's relevant, I just posted some error lines. If needed I can (A) truncate the files + (B) re-run passwd and then post the results. I ignored the DNS errors after I noticed in the logs that it's correctly resolving everything afterwords because it does a lookup on the SRV record (which I added to my BIND server), or at least it looks to be correct AFAICS. ldap_child.log: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP ldap_child.log: Received error from KDC: -1765328359/Additional pre-authentication required ... sssd_nss.log: Got reply from Data Provider - DP error code: 3 errno: 19 error message: Subdomains back end target is not configured sssd_nss.log: Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success ... sssd_MY.GREAT.DOMAIN.log: Could not get fully qualified name for host name linux-server.my.great.domain error [2]: No such file or directory, resolver returned: [4]: Domain name not found Thanks in advance, Bryan

3 5

Fwd: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA
by Dmitri Pal 29 May '13

29 May '13

Hello, The following Fedora 19 test day might be of interest for the SSSD community too. Thanks Dmitri -------- Original Message -------- Subject: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA Date: Tue, 28 May 2013 11:41:16 -0400 From: Dmitri Pal <dpal(a)redhat.com> Reply-To: dpal(a)redhat.com Organization: Red Hat To: freeipa-users(a)redhat.com <freeipa-users(a)redhat.com> The FreeIPA team is happy to welcome you to a Fedora Test Day that is being held on Thursday, June 6th. We invite you to take part in testing of the new OTP authentication feature that will become available in upcoming FreeIPA 3.2 upstream release and will be a part of Fedora 19. The feature is based on the new extended capabilities of the MIT Kerberos [1] and 389 directory server [2]. The feature would allow users to authenticate against FreeIPA and acquire Kerberos tickets using either OTP tokens issued by 3rd party vendors or by FreeIPA server itself. In the case the token is provided by a 3rd party vendor like RSA, VASCO, Yubico, etc. the authentication data is forwarded to the external authentication server over RADIUS protocol. In this scenario user input is supposed to consist of the two factors as prescribed by the vendor and will be handled by the external server. In case the OTP token is issued by FreeIPA itself the user can authenticate using two factors one of which is his Kerberos password and another one is a token issued for him. A token can be provisioned to his mobile device and used via Google authenticator app. This is an initial phase of the first ever integrated two factor authentication solution leveraging Kerberos SSO. When complete, users will be able to authenticate using different authentication methods and acquire tickets that will allow them to access different services within the enterprise depending on the strength of their authentication. More detailed information about the feature can be found here: https://fedoraproject.org/wiki/Feature/FreeIPA_Two_Factor_Authentication To read more about the test day and suggested tests see the following link https://fedoraproject.org/wiki/Test_Day:2013-06-06_FreeIPA_Two_Factor_Authe… Thank you for your help and participation! FreeIPA team [1] http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS [2] https://github.com/nkinder/otp_plugin _______________________________________________ Freeipa-users mailing list Freeipa-users(a)redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users

3 2

creating the temp file for SELinux data failed
by Sigbjorn Lie 24 May '13

24 May '13

Hi, I just updated SSSD on some RHEL servers, and after the upgrade I could not log on to 2 of the machines. The new version we're: sssd-client-1.9.2-82.7.el6_4.x86_64 sssd-1.9.2-82.7.el6_4.x86_64 I started sssd in debug mode and an error was displayed: (Thu May 23 22:31:58 2013) [sssd[pam]] [write_selinux_login_file] (0x0040): creating the temp file for SELinux data failed. /etc/selinux/targeted/logins/monmEKiSb(Thu May 23 22:31:58 2013) [sssd[pam]] [pam_reply] (0x0100): blen: 33 I proceeded to create the /etc/selinux/targeted/logins directory, restarted sssd, and now it works OK. Most machines upgraded without this issue. Is this an already known bug? Regards, Siggi

2 2

Problem with sssd and udev
by John Bossert 23 May '13

23 May '13

Am fighting a battle with sssd/ldap and udev (RHEL6/Centos6). I have a udev rule that sets disk ownership to oracle/asmadmin at boot. The user oracle and group asmadmin are registered in ldap. Other (udev) forums suggest that udev is executing before networking is enabled, ergo ldap is unreachable and the disks remain owned by root/root. Hmmm, could sssd caching be a solution? Following the various tutorials, I've enabled sssd, with "cache_credentials = TRUE" in sssd.conf, but I'm still seeing the same results. Either sssd caching isn't happening, or udev isn't making use of it. # getent --service=sss passwd oracle oracle:*:550:400:Oracle User:/home/oracle:/bin/bash # getent --service=sss group asmadmin asmadmin:*:403:oracle Any guidance, either to solve the problem else to obtain some useful diagnostics? John

3 5

Caching/performance issues with 1.5 vs 1.9
by Joshua C. Endries 23 May '13

23 May '13

Hello, I'm trying to get sssd going here to hook up with AD/LDAP for user and group lookup. I have it working, and it works great on RHEL5 (sssd v1.5.1). Running 'id' on myself takes 3s when in foreground mode, and 0.014s in service mode (service start...). Unfortunately, on RHEL6 (sssd v1.9.2), Running 'id' on myself takes 3-4min in foreground and 1min in service mode. This is with the same sssd.conf file. It looks like, when I look up my groups, it ends up looking up all the users in those groups, which 1.5 doesn't seem to do. We have a huge directory and caching all of this seems like a huge waste of resources... Is there a way to turn this off or modify this behavior? I tried reducing ldap_group_nesting_level but it didn't make a difference. Using ad instead of rfc2307bis didn't either. I didn't see anything else that looked like it would help... Thanks, Josh

4 5

IBM IHS Apache and SSSD
by Will_Darton＠navyfederal.org 23 May '13

23 May '13

4 9

How to change autofs auto.master name?
by C. S. 22 May '13

22 May '13

Hi folks, We have two auto.master maps: auto_master_a and auto_master_b. The reason for this is that it allows us to maintain the same paths at different campuses and redirect them to local filers vs. traversing a WAN link. In sssd I don't see an option to change the auto.master map name however, the cache expiring code seems to be hard coded to the string "auto.master". Looking at the code briefly I'm also not quite sure what the best way to add an ldap_autofs_master_map_name option would be, since it doesn't look like the configuration contexts are available in the provider and be code. Any suggestions appreciated. Thanks! cs

3 4

Re: [SSSD-users] Problem with sssd and udev
by John Bossert 21 May '13

21 May '13

Sorry for leaving out specifics. $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.3 (Santiago) $ sssd -version 1.8.0 The problem is that, during boot, udev is not correctly executing a rule to set user/group ownership, where the target user and group are maintained (exclusively) in LDAP. If, after boot, I re-execute start_udev, all works as expected.

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2013