sssd and no free space in var
by Евгений
Hi,
when ends space in / var, sssd does not allow to go through ssh, there is some solution to this problem?
Very important :)
Evgeniy
7 years, 6 months
Ldap referrals
by Ondrej Valousek
Hi list,
Is it safe to enable ldap referrals in sssd 13.3?
I have them disabled (ldap_referrals=false) but it seems to me that it is occasionally causing sssd to unable to find users in AD.
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
7 years, 6 months
ldap_idmap_range_size - different defaults between versions?
by Richard Collins
Hi,
Running Red Hat Enterprise Linux Server release 6.5 (Santiago) - 2.6.32-431.el6.x86_64
When running version sssd-1.9.2-129.el6.x86_64 users with objectSID/RID outside the default range (200,000) fail to convert and therefore cannot be authenticated. For example:
sssd-1.9.2-129.el6.x86_64 domain mapping:
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing [1] domains for ID-mapping
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x0100): Adding domain [###################-3828131906] as slice [9122]
(Tue Sep 20 14:36:00 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000): objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb
sssd-1.9.2-129.el6.x86_64 failed attempt:
(Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [###########################-200676] to a UNIX ID
(Tue Sep 20 14:39:52 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0040): Failed to save user [12345]
However, upgrading to version sssd-1.13.3-22.el6_8.4.x86_64 the problem disappears (no other changes to config have been made)
Note: I manually deleted the sss cache in /var/lib/sss/db before restarting with the new version:
sssd-1.13.3-22.el6_8.4.x86_64 domain mapping:
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_init] (0x0100): Initializing [1] domains for ID-mapping
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sdap_idmap_add_domain] (0x1000): Adding domain [S-1-5-21-1000884740-1136923486-3828131906] as slice [9122]
(Wed Sep 21 09:18:30 2016) [sssd[be[MYDOMAIN]]] [sysdb_idmap_dn] (0x4000): objectSID=###################-3828131906,cn=id_mappings,cn=MYDOMAIN,cn=sysdb
sssd-1.13.3-22.el6_8.4.x86_64 successful attempt:
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x1000): Mapping user [12345] objectSID [[###########################-200676] to unix ID
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x2000): Adding originalDN [CN=12345,OU=Users,OU=WAVE,OU=BusinessUnits,DC=MYDOMAIN] to attributes of [12345].
(Wed Sep 21 09:38:59 2016) [sssd[be[MYDOMAIN]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [12354].
According to the docs, the defaults for ldap_idmap_range_min, ldap_idmap_range_max and ldap_idmap_range_size haven't changed between versions.
While the issue is resolved - i.e. users with RID in excess of 200,000 can authenticate, I'm not clear why this now works and want to ensure I won't hit another limit in the near future. I'd like to avoid changing the mapping parameters as this alters the uid mapping and there will be a big task to clean up permissions on the file system.
Can anyone work out why this now works?
Thanks
Relevant server info:
AD controllers are WIN2012R2
SSSD is configured with a single domain
######begin sssd.conf#####
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = MYDOMAIN
debug_level = 9
[nss]
default_shell = /bin/bash
debug_level = 9
filter_users = root
filter_groups = root
[pam]
debug_level = 9
[sudo]
debug_level = 9
[domain/MYDOMAIN]
id_provider = ldap
access_provider = simple
cache_credentials = false
debug_level = 9
ldap_server = _srv_
ldap_search_base = #########
ldap_id_use_start_tls = true
ldap_tls_reqcert = allow
ldap_default_bind_dn = #########
ldap_default_authtok_type = password
ldap_default_authtok = #########
ldap_user_search_base = ou=BusinessUnits,dc=ad,dc=aib,dc=pri
ldap_user_object_class = user
ldap_id_mapping = true
ldap_schema = ad
ldap_group_search_base = #########
ldap_group_object_class = group
ldap_referrals = false
enumerate = false
override_homedir = /export/home/%u
ldap_group_nesting_level = 5
ldap_use_tokengroups = false
simple_allow_groups = sasi,sasadmin,sasmgt
ldap_access_order = expire
ldap_account_expire_policy = ad
######end sssd.conf#####
This document is strictly confidential and is intended for use by the addressee unless otherwise indicated. Allied Irish Banks AIB and AIB Group are registered business names of Allied Irish Banks p.l.c. Allied Irish Banks, p.l.c. is regulated by the Central Bank of Ireland. Registered Office: Bankcentre, Ballsbridge, Dublin 4. Tel: + 353 1 6600311; Registered in Ireland: Registered No. 24173. ~~~~~~~Please consider the environment before printing this Email~~~~~~~~ This email has been scanned by an external Email Security System. This Disclaimer has been generated by CMDis
7 years, 7 months
ldap_access_filter failure possibly caused by credentials/principle not found in Kerberos database
by klin938＠gmail.com
Hi all,
I am configuring AD authentication by using SSSD+kerberos on our CentOS 6.7 cluster. The solution works fine so far except that we could not use ldap_access_filter.
Whenever I enabled ldap_access_filter (add filter to ldap_access_order), all SSH logins are denied. And the error messages are:
==> /var/log/sssd/ldap_child.log <==
(Mon Sep 19 15:00:53 2016) [[sssd[ldap_child[12437]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU' not found in Kerberos database
(Mon Sep 19 15:00:53 2016) [[sssd[ldap_child[12437]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
(Mon Sep 19 15:00:53 2016) [[sssd[ldap_child[12438]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU' not found in Kerberos database
(Mon Sep 19 15:00:53 2016) [[sssd[ldap_child[12438]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12501]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU' not found in Kerberos database
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12501]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12502]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU' not found in Kerberos database
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12502]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12503]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU' not found in Kerberos database
(Mon Sep 19 15:02:45 2016) [[sssd[ldap_child[12503]]]] [main] (0x0020): ldap_child_get_tgt_sync failed.
But I believe the entry is in the keytab file already:
[root@nerv-geofront ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
5 host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU (des-cbc-crc)
5 host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU (des-cbc-md5)
5 host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU (aes128-cts-hmac-sha1-96)
5 host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU (aes256-cts-hmac-sha1-96)
5 host/nerv-geofront.local(a)AD.EXAMPLE.EDU.AU (arcfour-hmac)
5 host/nerv-geofront(a)AD.EXAMPLE.EDU.AU (des-cbc-crc)
5 host/nerv-geofront(a)AD.EXAMPLE.EDU.AU (des-cbc-md5)
5 host/nerv-geofront(a)AD.EXAMPLE.EDU.AU (aes128-cts-hmac-sha1-96)
5 host/nerv-geofront(a)AD.EXAMPLE.EDU.AU (aes256-cts-hmac-sha1-96)
5 host/nerv-geofront(a)AD.EXAMPLE.EDU.AU (arcfour-hmac)
5 NERV-GEOFRONT$(a)AD.EXAMPLE.EDU.AU (des-cbc-crc)
5 NERV-GEOFRONT$(a)AD.EXAMPLE.EDU.AU (des-cbc-md5)
5 NERV-GEOFRONT$(a)AD.EXAMPLE.EDU.AU (aes128-cts-hmac-sha1-96)
5 NERV-GEOFRONT$(a)AD.EXAMPLE.EDU.AU (aes256-cts-hmac-sha1-96)
5 NERV-GEOFRONT$(a)AD.EXAMPLE.EDU.AU (arcfour-hmac)
The error messages above appear only when I enabled ldap_access_filter, so I think this is related to the kerberos keytab.
I am testing on sssd 1.12.4, samba 3.6.23.
Any idea will be appreciated.
Cheers,
Derrick
7 years, 7 months
pwdReset TRUE not working
by xcorvis＠gmail.com
I have an environment set up with OpenLDAP, ppolicy and sssd on Ubuntu 12.04. I've got ppolicy working fine, for the most part, but I'm trying to set pwdReset: TRUE in LDAP to force users to change passwords and it's not having any effect. I have pwdMustChange: TRUE in the default password policy, and password prompts for expired passwords works, so I know it's not grossly misconfigured or something.
I've spent a few days looking into this and from other posts and blogs it sounds like pwdReset can be handled by sssd and is somehow enforced by pam, but I'm not seeing any error messages about pam or password resets (pam verbosity 3 and debug_level 9). With the lack of errors, I'm basically wondering what are the requirements to get pwdReset functioning with sssd?
Thanks.
7 years, 7 months
Re: pwdReset TRUE not working
by Douglas Duckworth
I got this working on Centos 6 using the following for password-auth-ac /
system-auth-ac.
#%PAM-1.0
# pam_succeed_if.so in auth MUST be sufficient
# pam_succeed_if.so in account does not currently work with uid under 500
and pwdReset:TRUE in OpenLDAP
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.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 sufficient pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so sha512 shadow nullok try_first_pass
use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session sufficient pam_sss.so
session required pam_unix.so
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-5454
F: 212-746-8690
On Thu, Aug 25, 2016 at 4:59 PM, Lukas Slebodnik <lslebodn(a)redhat.com>
wrote:
> On (25/08/16 20:44), xcorvis(a)gmail.com wrote:
> >I have an environment set up with OpenLDAP, ppolicy and sssd on Ubuntu
> 12.04. I've got ppolicy working fine, for the most part, but I'm trying to
> set pwdReset: TRUE in LDAP to force users to change passwords and it's not
> having any effect. I have pwdMustChange: TRUE in the default password
> policy, and password prompts for expired passwords works, so I know it's
> not grossly misconfigured or something.
> >
> >I've spent a few days looking into this and from other posts and blogs it
> sounds like pwdReset can be handled by sssd and is somehow enforced by pam,
> but I'm not seeing any error messages about pam or password resets (pam
> verbosity 3 and debug_level 9). With the lack of errors, I'm basically
> wondering what are the requirements to get pwdReset functioning with sssd?
> >
> Ubuntu 12.04 seems to have sssd 1.8.2
> The ppa[2] seems to have 1.11.5
>
> It would be good to test with more recent version of sssd.
> You can try sssd in 16.04.
>
> I can confirm that "pwdReset: TRUE" works with latest sssd 1.13
> which is in xenial(16.04)
>
> LS
>
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__
> packages.ubuntu.com_search-3Fkeywords-3Dsssd-26searchon-
> 3Dnames-26suite-3Dprecise-26section-3Dall&d=DQIGaQ&c=
> lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> CbhH6xUjnRkaqPFUS2wTJ2cw&m=e5O5zPnwDumy2ONJT4dlFcqr7saa51Qy72hsJc4f87I&s=
> N0Lii3TQAhrxxkHAsA1mnnJH_nzNooMhVjkJW9AGhio&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__
> launchpad.net_-7Esssd_-2Barchive_ubuntu_updates&d=DQIGaQ&c=
> lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> CbhH6xUjnRkaqPFUS2wTJ2cw&m=e5O5zPnwDumy2ONJT4dlFcqr7saa51Qy72hsJc4f87I&s=
> Ql0q2KebQkGKdDX18BnMX8kAgrDhOP5veCzFmLu1GRg&e=
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> fedorahosted.org_admin_lists_sssd-2Dusers-40lists.
> fedorahosted.org&d=DQIGaQ&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> e5O5zPnwDumy2ONJT4dlFcqr7saa51Qy72hsJc4f87I&s=
> Ik1cAF4mlAZIwL7EXJakHVYvpY3FXgdmwJFM3W4qNp4&e=
>
7 years, 7 months
How to pam authenticate against the hash in userPassword attribute?
by Bernd Leibing
I'm using sssd 1.13.3 and try to configure sssd for nss and pam both against our
openldap server. Nss seems to work but pam doesn't.
# getent passwd timap
timap:*:41848:400:Test Imap:/users/org1/timap:/usr/local/bin/bash
but login of the timap user fails:
syslog output:
login[2315]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0
tty=tty1 ruser= rhost= user=timap
login[2315]: pam_sss(login:auth): received for user timap: 7 (Authentication failure)
login[2315]: FAILED LOGIN 1 FROM tty1 FOR timap, Authentication failure
Maybe we have an unusal ldap server setup. There is a privileged DN
cn=roadmin,ou=people,ou=admin,dc=myorg,dc=de
to access all posixAccount objects.
a user Account has this attributes:
# ldapsearch -x -w secret -D "cn=roadmin,ou=people,ou=admin,dc=myorg,dc=de"
'(&(uid=timap)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))'
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=myorg,dc=de> (default) with scope subtree
# filter: (&(uid=timap)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))
# requesting: ALL
#
# timap, people, myorg.de
dn: uid=timap,ou=people,dc=myorg,dc=de
userPassword:: e0NSWVBUfSQ2JDV5N1B5RC84N3pRY2VmZlgkMk1LQjAxc1pFNzBzYXFsOUhZNWo
3WFhJSVZXOWMuTHdOZEZpMzV5UVpzYlN0ZGpLVDVhdVdKeWRlcVdBSDMySmhwanZMNGJkZnVhYXMy
SVFxVG41Yi8=
cn: timap
gecos: Test Imap
gidNumber: 400
homeDirectory: /users/org1/timap
loginShell: /usr/local/bin/bash
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
uid: timap
uidNumber: 41848
My configuration is
--------/etc/sssd/sssd.conf-------------------
[sssd]
config_file_version = 2
services = nss,pam
domains = LDAP
[nss]
filter_groups = root
filter_users = root
[pam]
pam_verbosity = 3
[domain/LDAP]
debug_level = 0xFFF0
ldap_uri = ldaps://ldapserver.myorg.de
ldap_search_base = dc=myorg,dc=de
ldap_schema = rfc2307
id_provider = ldap
ldap_id_use_start_tls = True
enumerate = False
cache_credentials = True
chpass_provider = ldap
auth_provider = ldap
ldap_tls_cacertdir = /var/ldap
ldap_tls_cacert = /var/ldap/certdb.pem
ldap_tls_reqcert = demand
ldap_default_bind_dn = cn=roadmin,ou=people,ou=admin,dc=myorg,dc=de
ldap_default_authtok_type = password
ldap_default_authtok = secret
---------------------------------------
--------/etc/nsswitch.conf-------------
passwd: files sss
group: files sss
shadow: files sss
hosts: files dns
---------------------------------------
Excerpt of sssd_LDAP.log:
[sssd[be[LDAP]]] [simple_bind_done] (0x0400): Bind result: Success(0), no errmsg set
[sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as:
cn=roadmin,ou=people,ou=admin,dc=myorg,dc=de
[sssd[be[LDAP]]] [set_server_common_status] (0x0100): Marking server
'ldapserver.myorg.de' as 'working'
[sssd[be[LDAP]]] [be_get_account_info] (0x0200): Got request for [0x1001][FAST
BE_REQ_USER][1][name=timap]
[sssd[be[LDAP]]] [be_req_set_domain] (0x0400): Changing request domain from [LDAP] to
[LDAP]
[sssd[be[LDAP]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
[sssd[be[LDAP]]] [sdap_search_user_next_base] (0x0400): Searching for users with base
[dc=myorg,dc=de]
[sssd[be[LDAP]]] [sdap_print_server] (0x2000): Searching xxx.xxx.xxx.xxx
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(uid=timap)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=myorg,dc=de].
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs:
[krbPrincipalName]
[sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
[sssd[be[LDAP]]] [sdap_parse_entry] (0x1000): OriginalDN:
[uid=timap,ou=people,dc=myorg,dc=de].
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [userPassword]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [gecos]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [homeDirectory]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [loginShell]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [uid]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [uidNumber]
[sssd[be[LDAP]]] [sdap_parse_range] (0x2000): No sub-attributes for [modifyTimestamp]
[sssd[be[LDAP]]] [sdap_save_user] (0x2000): Adding originalDN
[uid=timap,ou=people,dc=myorg,dc=de] to attributes of [timap].
[sssd[be[LDAP]]] [sdap_save_user] (0x0400): Storing info for user timap
So far this looks good. nss is working, but the pam request not!
Pam is using an additional simple_bind as
uid=timap,ou=people,dc=myorg,dc=de
instead of directly authenticating against the hash of the timap userPassword
attribute we already got from the ldap request above
[sssd[be[LDAP]]] [be_req_set_domain] (0x0400): Changing request domain from [LDAP] to
[LDAP]
[sssd[be[LDAP]]] [be_pam_handler] (0x0100): Got request with the following data
[sssd[be[LDAP]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
[sssd[be[LDAP]]] [pam_print_data] (0x0100): domain: LDAP
[sssd[be[LDAP]]] [pam_print_data] (0x0100): user: timap
[sssd[be[LDAP]]] [pam_print_data] (0x0100): service: login
[sssd[be[LDAP]]] [pam_print_data] (0x0100): tty: tty1
[sssd[be[LDAP]]] [pam_print_data] (0x0100): ruser:
[sssd[be[LDAP]]] [pam_print_data] (0x0100): rhost:
[sssd[be[LDAP]]] [pam_print_data] (0x0100): authtok type: 1
[sssd[be[LDAP]]] [pam_print_data] (0x0100): newauthtok type: 0
[sssd[be[LDAP]]] [pam_print_data] (0x0100): priv: 1
[sssd[be[LDAP]]] [pam_print_data] (0x0100): cli_pid: 1863
[sssd[be[LDAP]]] [pam_print_data] (0x0100): logon name: not set
[sssd[be[LDAP]]] [simple_bind_send] (0x0100): Executing simple bind as:
uid=timap,ou=people,dc=myorg,dc=de
[sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 1
[sssd[be[LDAP]]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49),
no errmsg set
Does anyone have an idea howto configure sssd to authenticate against hash in the
userPassword attribute of the timap account
The complete log is attached
Bing
7 years, 7 months
Network coming up slowly causing sssd to fail on startup
by Ondrej Valousek
Hi List,
Just experiencing troubles when starting machine.
The thing is that by the time sssd starts, network is not quite ready - sometimes Cisco switches take up to few seconds to negotiate speed, etc -> network sysinit script already finishes (could happen if you have static IP, right?), sssd comes up, got offline, the automounter starts and fails to mount directories.
Have you ever seen this?
Who to blame? Network init scripts or sssd?
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
7 years, 7 months
Re: Network coming up slowly causing sssd to fail on startup
by Ondrej Valousek
Update:
The server is connected via bonding interface.
I guess that could be the problem.
Ondrej
From: Ondrej Valousek
Sent: Thursday, September 15, 2016 11:22 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: Network coming up slowly causing sssd to fail on startup
Hi List,
Just experiencing troubles when starting machine.
The thing is that by the time sssd starts, network is not quite ready - sometimes Cisco switches take up to few seconds to negotiate speed, etc -> network sysinit script already finishes (could happen if you have static IP, right?), sssd comes up, got offline, the automounter starts and fails to mount directories.
Have you ever seen this?
Who to blame? Network init scripts or sssd?
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
7 years, 7 months
