Ubuntu Saucy sssd-1.11.0 not starting
by Longina Przybyszewska
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
10 years, 6 months
ssh openldap and sssd
by Olivier
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
10 years, 6 months
sssd, autofs and active directory
by Rowland Penny
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" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->
<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
10 years, 6 months
how do I restrict access when access_provider = ad ?
by Doug Clow
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
10 years, 6 months
Active Directory parent-child trust
by Alfredo Colangelo
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
10 years, 6 months
Re: [SSSD-users] Need help configuring fine grained password policy
by Bright, Daniel
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
10 years, 6 months
Need help configuring fine grained password policy
by Bright, Daniel
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.
10 years, 6 months
Re: [SSSD-users] Need help configuring fine grained password policy enforcement on RHEL6 using sssd
by Bright, Daniel
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
10 years, 6 months
Need help configuring fine grained password policy enforcement on RHEL6 using sssd
by Bright, Daniel
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.
10 years, 6 months
bad basedn with autofs in sssd
by Dale Harris
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
/.-)
10 years, 6 months