sssd-users September 2013

sssd-users@lists.fedorahosted.org

23 participants
22 discussions

Ubuntu Saucy sssd-1.11.0 not starting
by Longina Przybyszewska 23 Sep '13

23 Sep '13

Hi, I would test the new features (autofs !!!) in sssd-1.11.0 version in Ubuntu Saucy, and I am using native sssd package. I use working config file from sssd-1.9.4 Daemon doesn't start: root@saucy:/var/lib/sss# sssd -i (Mon Sep 9 18:30:36:657103 2013) [sssd] [confdb_init_db] (0x0010): Config file version could not be determined (Mon Sep 9 18:30:36:657280 2013) [sssd] [load_configuration] (0x0010): ConfDB initialization has failed [Input/output error] (Mon Sep 9 18:30:36:657466 2013) [sssd] [main] (0x0020): SSSD couldn't load the configuration database. root@saucy:/var/lib/sss# sssd -d 9 -i (Mon Sep 9 18:30:54:183407 2013) [sssd] [check_file] (0x0400): lstat for [/var/run/nscd/socket] failed: [2][No such file or directory]. (Mon Sep 9 18:30:54:205801 2013) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! (Mon Sep 9 18:30:54:346409 2013) [sssd] [ldb] (0x4000): no modules required by the db (Mon Sep 9 18:30:54:346850 2013) [sssd] [ldb] (0x4000): No modules specified for this database (Mon Sep 9 18:30:54:347236 2013) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:358172 2013) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:368474 2013) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:378564 2013) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:388571 2013) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:398769 2013) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Sep 9 18:30:54:410711 2013) [sssd] [confdb_init_db] (0x0010): Config file version could not be determined (Mon Sep 9 18:30:54:411510 2013) [sssd] [load_configuration] (0x0010): ConfDB initialization has failed [Input/output error] (Mon Sep 9 18:30:54:412372 2013) [sssd] [main] (0x0020): SSSD couldn't load the configuration database. root@saucy:/var/lib/sss# ls -l db total 1256 -rw------- 1 root root 1286144 Sep 9 18:30 config.ldb Best Longina

2 15

ssh openldap and sssd
by Olivier 20 Sep '13

20 Sep '13

Hi everyone, I found this thread about openldap served ssh keys and sssd integration : https://lists.fedorahosted.org/pipermail/sssd-users/2013-March/000442.html then I subscribed to this list :-) I try to make that work but I stay stick : could you help ? Here is where I am: 1- I have loaded "openssh-lpk_openldap.schema" in openldap 2- I have configured my account in the directory to know about "sshPublicKey" attribute, and I have inserted my key : # ldapsearch -x -h localhost -b dc=guillard,dc=corp "(uid=olivier)" sshPublicKey dn: uid=olivier,dc=guillard,dc=corp sshPublicKey: ssh-dss AAAAB3NzaC1kc3MAAAEBAKXF ..... BaO51jw8RUAt1u5QDa3UQiQ6X8Vq0j2MUh3LeXfk= guillard@corp 3- I also have configured sssd to tell him to look up for ssh keys in ldap: # cat /etc/sssd/sssd.conf: [domain/default] ... (the conf is correct: everything works fine for login§/passwords for example) # I have added this in the default/section ldap_user_ssh_public_key = True [sssd] services = nss, pam, ssh domains = default [nss] [pam] [ssh] 4- I have restarted sssd (I get no error) And now I'm stuck # /usr/bin/sss_ssh_authorizedkeys olivier -> does not return anything Anyone could help : what have I forgotten ? Any indication about what I should add in ssh_config to tell sshd to look for keys in sssd cache would also help. Thanks ! --- Olivier

2 3

sssd, autofs and active directory
by Rowland Penny 18 Sep '13

18 Sep '13

Hello, I have inserted the automount schema into Samba 4 AD and got it to work (for those thinking that it will not work, try changing the two objectClasses to auxillary not structural) I can now add the following ldif to the AD database: dn: OU=automount,DC=example,DC=com objectClass: top objectClass: organizationalUnit ou: automount name: automount dn: OU=auto.master,OU=automount,DC=example,DC=com objectClass: top objectClass: automountMap objectClass: organizationalUnit ou: auto.master name: auto.master automountMapName: auto.master dn: CN=/shares,OU=auto.master,OU=automount,DC=example,DC=com objectClass: top objectClass: automount objectClass: container cn: /shares name: /shares automountKey: /shares automountInformation: auto.shares dn: OU=auto.shares,OU=automount,DC=example,DC=com objectClass: top objectClass: automountMap objectClass: organizationalUnit ou: auto.shares name: auto.shares automountMapName: auto.shares dn: CN=dropbox,OU=auto.shares,OU=automount,DC=example,DC=com objectClass: top objectClass: automount objectClass: container cn: dropbox name: dropbox automountKey: dropbox automountInformation: -fstype=cifs,rw,username=rowland,password=xxxxxxxxxx,uid=3001106,iocharset=utf8 ://192.168.0.2/dropbox And if I setup the client as follows: /etc/default/autofs MASTER_MAP_NAME="OU=auto.master,OU=automount,DC=example,DC=com" LOGGING="verbose" LDAP_URI="ldap://homeserver.example.com" # AD server name SEARCH_BASE="OU=automount,DC=example,DC=com" MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="automountMapName" ENTRY_ATTRIBUTE="automountKey" VALUE_ATTRIBUTE="automountInformation" AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf" /etc/autofs_ldap_auth.conf <?xml version="1.0" ?>  <autofs_ldap_sasl_conf usetls="no" tlsrequired="no" authrequired="yes" authtype="GSSAPI" clientprinc="THINKPAD$(a)EXAMPLE.COM" /> /etc/nsswitch.conf ........... automount: ldap It works! I can browse to the mount point and the share from the server is mounted. If I now modify sssd to control autofs. [sssd] config_file_version = 2 domains = example.com services = nss, pam,autofs [nss] [pam] [autofs] [domain/example.com] description = AD domain with Samba 4 server cache_credentials = true enumerate = false id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap krb5_server = server.example.com krb5_kpasswd = server.example.com krb5_realm = EXAMPLE.COM ldap_referrals = false ldap_schema = rfc2307bis ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = sAMAccountName autofs_provider = ldap ldap_sasl_mech = GSSAPI ldap_autofs_search_base = OU=automount,DC=example,DC=com ldap_autofs_map_object_class = automountMap ldap_autofs_entry_object_class = automount ldap_autofs_map_name = automountMapName ldap_autofs_entry_key = automountKey ldap_autofs_entry_value = automountInformation /etc/nsswitch.conf ........... automount: sss sudo service sssd restart sudo service autofs restart autofs now no longer works. If we look in the logs we find: /var/log/syslog Sep 16 15:10:50 ThinkPad automount[4056]: Starting automounter version 5.0.7, master map OU=auto.master,OU=automount,DC=example,DC=com Sep 16 15:10:50 ThinkPad automount[4056]: using kernel protocol version 5.02 Sep 16 15:10:50 ThinkPad automount[4056]: setautomntent: lookup(sss): setautomntent: No such file or directory Sep 16 15:10:50 ThinkPad automount[4056]: no mounts in table /var/log/sssd/sssd_example.com.log (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))][OU=automount,DC=example,DC=com]. (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [automountMapName] (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7166f0], connected[1], ops[0x725020], ldap[0x6e04b0] (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_get_automntmap_process] (0x0400): Search for autofs maps, returned 0 results. (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_autofs_setautomntent_done] (0x0080): Could not find automount map (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sysdb_delete_autofsmap] (0x0400): Deleting autofs map OU=auto.master,OU=automount,DC=example,DC=com (Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [be_autofs_handler_callback] (0x1000): Request processed. Returned 0,0,Success sssd seems to be searching using this filter: (&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))][OU=automount,DC=example,DC=com]. which means to me, search in the base 'OU=automount,DC=example,DC=com' for the attribute 'automountMapName' which contains 'OU=auto.master,OU=automount,DC=example,DC=com' AND the DN that contains 'automountMapName' must also contain the objectClass 'automountMap' Is this correct? If I am correct, then I think that sssd is never going to work with autofs & AD as is, even though Steve assures me it does. This is because, even though the DN 'OU=auto.master,OU=automount,DC=example,DC=com' has the objectClass 'automountMap' and does contain the attribute 'automountMapName' this contains 'auto.shares' not 'OU=auto.master,OU=automount,DC=example,DC=com'. The problem, as I see it, is that in LDAP you can have a DN such as 'automountMapName=auto.master,cn=automount,dc=example,dc=com', but this would seem to be not allowed in AD, I cannot add an ldif using such a template I have tried both the NIS setup and the one above and they all fail in the same way for me, i.e they work perfectly if I use ldap in nsswitch.conf but will not work if I try to use sssd. Can anybody see where I am going wrong? By the way, I based this setup on a blog by some guy named Jakub Hrozek which I found here: http://jhrozek.livejournal.com/2012/05/01/ Rowland

3 9

how do I restrict access when access_provider = ad ?
by Doug Clow 16 Sep '13

16 Sep '13

Hello, I recently switched my sssd to 1.9 so I can try the native Active Directory support. Previously I was using: id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap And now with 1.9 I'm using: id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad This works great except for one thing. ldap_access_filter no longer does anything so everyone can log into all the machines. When I'm using access_provider = ad how do I restrict which users and groups have access to the machine? Thanks, Doug

3 7

Active Directory parent-child trust
by Alfredo Colangelo 16 Sep '13

16 Sep '13

Hello List, I've built sssd-1.11.90 from git source for a CentOS 6.4 server. I want to set up a connection with SSSD to 2 Active Directory domains (both Windows 2003 functional level), parent and child, so they have a parent-child transitive trust: ad.example.com \_child.ad.example.com I've joined the server to the parent domain using the ad provider, that (from 1.10 on) supports AD trusts. I'm expecting to be able to login (via ssh) to the server both using " testuser(a)ad.example.com" (which works), and using " testuser(a)child.ad.example.com" which doesen't work. This is what I want to fix. If I join the server to the child domain I am able to login with users from child domain (as expected), but not with users from parent domain. My guess is that trust isn't working. Running "getent passwd" enumerates users only from the parent domain, but nothing from the child domain. This is sssd.conf contents: [sssd] services = nss, pam config_file_version = 2 domains = ad.example.com [domain/ad.example.com] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ad_server = dc1.ad.example.com ad_backup_server = dc2.ad.example.com filter_users = root(a)ad.example.com filter_groups = root(a)ad.example.com ldap_id_mapping = false dyndns_update = true dyndns_update_ptr = false enumerate = true subdomain_enumerate = all cache_credentials = true I'm not using ID Mapping, I'm using posix attributes from AD, but even enabling ID mapping the result doesen't change. Am I doing something the wrong way ? Is it possible the problem is that the domains are not Windows 2008 R2 (as of documentation the only supported configuration for the AD provider) ? Thanks, Alfredo

2 1

Re: [SSSD-users] Need help configuring fine grained password policy
by Bright, Daniel 13 Sep '13

13 Sep '13

Jakub, Thanks for the response, I figured out why I was getting the constraint violation, in my case it was because I have the "passwordminage" set for my policy, when I changed the user attribute "passwordallowchangetime" to the current date then I was able to perform the passwd operation. So at this point I believe the password policy is being applied, however I am just not getting all of the responses I would like, I get things like "password is too short", "your password will expire in X days", but I would expect to get something like "You cannot change your password again for X days" from the above This leads me to another question, is there a way I can map certain responses to responses that I define? Thanks, Daniel B

3 4

Need help configuring fine grained password policy
by Bright, Daniel 12 Sep '13

12 Sep '13

Jakub, I took your advice and turned debugging to level 9, this is what I am seeing in the logs: ======================================================================================================= [root(a)some.server.com sssd]# tail -f sssd_LDAP.log | grep sdap_exop (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x0100): Executing extended operation (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x2000): ldap_extended_operation sent, msgid = 3 (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0200): Server returned no controls. (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0080): ldap_extended_operation result: Constraint violation(19), Failed to update password ======================================================================================================= Here is some more relevant log information: ======================================================================================================= [root(a)some.server.com sssd]# tail -f sssd_LDAP.log | grep sdap_exop (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x0100): Executing extended operation (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x2000): ldap_extended_operation sent, msgid = 3 (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0200): Server returned no controls. (Thu Sep 12 09:44:57 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0080): ldap_extended_operation result: Constraint violation(19), Failed to update password (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x90d340], connected[1], ops[0x9cb7d0], ldap[0x9e8030] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'atl01osd110.vsi.com' as 'working' (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [set_server_common_status] (0x0100): Marking server 'atl01osd110.vsi.com' as 'working' (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x98db10 (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x9e8cf0 (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [ldb] (0x4000): Destroying timer event 0x9e8cf0 "ltdb_timeout" (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [ldb] (0x4000): Ending timer event 0x98db10 "ltdb_callback" (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [find_password_expiration_attributes] (0x4000): No password policy requested. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=user1,ou=People,dc=some,dc=company,dc=com (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x90d340], connected[1], ops[0x900e80], ldap[0x9e8030] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x90d340], connected[1], ops[0x900e80], ldap[0x9e8030] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1]. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x1000): Password Policy Response: expire [346806] grace [-1] error [No error]. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x1000): Password will expire in [346806] seconds. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x2000): Server returned control [2.16.840.1.113730.3.4.5]. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x1000): Password will expire in [346806] seconds. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [simple_bind_done] (0x0400): Bind result: Success(0), no errmsg set (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [auth_bind_user_done] (0x4000): Found ppolicy data, assuming LDAP password policies are active. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_auth4chpass_done] (0x1000): user [uid=user1,ou=People,dc=some,dc=company,dc=com] successfully authenticated. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_control_create] (0x0080): Server does not support the requested control [1.3.6.1.4.1.42.2.27.8.5.1]. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x0100): Executing extended operation (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_send] (0x2000): ldap_extended_operation sent, msgid = 3 (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x90d340], connected[1], ops[0x9bf740], ldap[0x9e8030] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x90d340], connected[1], ops[0x9bf740], ldap[0x9e8030] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0200): Server returned no controls. (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_exop_modify_passwd_done] (0x0080): ldap_extended_operation result: Constraint violation(19), Failed to update password (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 12, <NULL>) [Internal Error (Authentication token is no longer valid; new one required)] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [be_pam_handler_callback] (0x0100): Sending result [12][LDAP] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [be_pam_handler_callback] (0x0100): Sent result [12][LDAP] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): Trace: sh[0x90d340], connected[1], ops[(nil)], ldap[0x9e8030], destructor_lock[0], release_memory[0] (Thu Sep 12 09:54:50 2013) [sssd[be[LDAP]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. ======================================================================================================= I noticed it says "Server does not support the requested control [1.3.6.1.4.1.42.2.27.8.5.1]" looking at my 389-ds schema my password policy OID = 2.16.840.1.113730.3.2.13, could this be the issue? Thanks, Daniel B.

3 2

Re: [SSSD-users] Need help configuring fine grained password policy enforcement on RHEL6 using sssd
by Bright, Daniel 12 Sep '13

12 Sep '13

Jakub, Thanks for the quick response, to answer your question I am using the built-in password policy features of 389-ds that allows us to use these features: Maximum Number of Failures Password Change After Reset User-Defined Passwords Password Expiration Expiration Warning Grace Login Limit Password Syntax Checking Password Length Password Minimum Age Password History Password Storage Schemes Password Last Change Time Here is a sanitized version of ldap.conf that is used in our current environment: =========================================================================== host ldap1 ldap2 URI ldap://ldap1:389 ldap://ldap2:389 base dc=some,dc=company,dc=com #bind_timelimit 5 #>> bind_timelimit 3 bind_policy soft timelimit 3 #^^ ldap_version 3 pam_lookup_policy yes pam_filter objectclass=posixAccount pam_password md5 nss_base_passwd ou=People,dc=some,dc=company,dc=com?one nss_base_passwd ou=Disabled Users,dc=some,dc=company,dc=com?one nss_base_shadow ou=People,dc=some,dc=company,dc=com?one nss_base_group ou=Groups,dc=some,dc=company,dc=com?one?|(host=\2A)(host=osd) #>> nss_initgroups_ignoreusers root,ldap #^^ ssl start_tls #ssl on tls_cacertdir /etc/openldap/cacerts =========================================================================== Thanks, Daniel Bright

3 2

Need help configuring fine grained password policy enforcement on RHEL6 using sssd
by Bright, Daniel 11 Sep '13

11 Sep '13

I was told by the good folks at the 389-users mailing list to instead redirect my question to the sssd-users list so here goes, thanks in advance! All, I am in the process of moving away from pam_ldap and on to pam_sss. The basic sssd setup is working just fine, user authentication works, getent passwd works, caching is great, everything looks like it's working fine except for password policy enforcement. I am wondering if there is some sort of password policy overlay I need to use, or a special setup of sssd.conf, I tried using "ldap_pwd_policy=shadow" however this doesn't allow me to change passwords, I instead get this error: [user1@someserver ~]$ passwd Changing password for user user1. Current Password: New password: Retype new password: Password change failed. Server message: Failed to update password (3 second delay here) passwd: Authentication token is no longer valid; new one required As soon as I comment out ldap_pwd_policy=shadow this error goes away, however so does my password policy enfocement. If anyone could help it would be greatly appreciated, I will post a working config on my blog after this is done so we can help others too. Thanks! Daniel B.

2 1

bad basedn with autofs in sssd
by Dale Harris 11 Sep '13

11 Sep '13

Hi folks, Trying to set up autofs in sssd. It doesn't appear that sssd likes my basedn, one that I use on Solaris just fine. In my sssd_default.log I see: sssd_default.log:(Tue Sep 10 23:59:59 2013) [sssd[be[default]]] [common_parse_search_base] (0x0020): Invalid base DN ["o=nycornell.org"] I'm running RHEL 6.4. sssd-1.9.2-82.7 libsss_autofs-1.9.2-82.7 User authentication in with sss/ldap works just fine. Any suggestions? Changing my basedn will be impossible. -- Dale Harris rodmur(a)maybe.org rodmur(a)gmail.com /.-)

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2013