TLS connect error?
by Aaron Jenkins
Hi,
I have a server running ApacheDS with both SSL and TLS enabled with a valid keystore. It allows me to connect via other ldap clients on both SSL and StartTLS and I’m able to use Kerberos from the client machine.
However, when I configure sssd on a client machine to use ldap and use the ApacheDS as it’s provider, it fails with the message
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): domain: AUTOMATON.UK
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): user: aaron.jenkins
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): service: login
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): tty: /dev/pts/15
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): ruser:
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): rhost:
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): authtok type: 1
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): newauthtok type: 0
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): priv: 1
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [pam_print_data] (0x0100): cli_pid: 9586
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [be_resolve_server_process] (0x0200): Found address for server ds.automaton.uk: [10.211.55.27] TTL 7200
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [sdap_sys_connect_done] (0x0100): Executing START TLS
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null)
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [(unknown error code)]
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [fo_set_port_status] (0x0100): Marking port 10389 of server 'ds.automaton.uk' as 'not working'
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [be_pam_handler_callback] (0x0100): Backend returned: (1, 9, <NULL>) [Provider is Offline (Authentication service cannot retrieve authentication info)]
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [be_pam_handler_callback] (0x0100): Sending result [9][AUTOMATON.UK]
(Thu Nov 13 19:19:50 2014) [sssd[be[AUTOMATON.UK]]] [be_pam_handler_callback] (0x0100): Sent result [9][AUTOMATON.UK]
My sssd configuration is as follows:
[sssd]
config_file_version = 2
services = nss, pam
domains = AUTOMATON.UK
debug_level = 5
[domain/AUTOMATON.UK]
debug_level = 5
cache_credentials = true
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ds.automaton.uk:10389
ldap_search_base = dc=automaton,dc=uk
chpass_provider = ldap
entry_cache_timeout = 600
ldap_network_timeout = 2
The search base and the uri is correct as it works with other things. Do you guys have any idea what could be going wrong?
9 years, 5 months
Domain group membership troubles with sssd and AD provider (1.12.2)
by Sergey Urushkin
I have sssd (1.12.2 on archlinux, 1.11.5 on ubuntu 14.04, 1.11.7 on
ubuntu 14.10, i386) configured against samba4 (4.1.11, ubuntu 14.04,
amd64) using AD provider:
[sssd]
config_file_version = 2
reconnection_retries = 2
services = nss, pam
domains = DOMAIN.COM
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 2
[pam]
reconnection_retries = 2
[domain/DOMAIN.COM]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
ldap_user_gecos = displayName
ldap_tls_reqcert = allow
ldap_sasl_mech = gssapi
ldap_sasl_authid = nix$(a)DOMAIN.COM
krb5_use_enterprise_principal = false
krb5_keytab = /etc/sssd/sssd.keytab
ldap_id_mapping = false
dyndns_update = false
cache_credentials = true
enumerate = false
min_id = 1
I have sudo and sshd configured to use groups:
# grep group1 /etc/ssh/sshd_config
AllowGroups root group1
# grep group1 /etc/sudoers
%group1 ALL=(ALL) ALL
User 'user4' is a member of several domain posix not nested groups,
including 'group1'. No local group membership.
After starting sssd (with empty /var/lib/sss). Authentication and local
logon works fine. 'getent group' shows correct group members:
# getent group group1
group1:*:1013:user1,user2,user3,user4,user5
... but 'id' shows primary group only:
# id user4
uid=1104(user4) gid=513(domain users) groups=513(domain users)
Now, trying to use sudo (local):
$ sudo -s
[sudo] password for user4:
user4 is not in the sudoers file. This incident will be reported.
... or login remotely via ssh (sshd log message):
User user4 from host.domain.com not allowed because none of user's
groups are listed in AllowGroups
After this, 'id' output stays the same:
# id user4
uid=1104(user4) gid=513(domain users) groups=513(domain users)
But 'user4' dissapears from 'getent group' output:
# getent group group1
group1:*:1013:user1,user2,user3,user5
Restarting sssd doesn't fix the issue. User appears in group list again
only after removing 'db/cache_DOMAIN.COM.ldb' file and restarting sssd.
But disappears again after the same actions (ssh/sudo). Next options
doesn't help too:
ldap_id_mapping = true
enumerate = true
winbind 4.1 works absolutely fine against the same AD server. So, I
think the problem is about sssd...
Summary:
* sssd group membership ACL checks don't work. User disappears from
'getent group' output after such check.
* 'id' shows primary group only
Should I file a bug report?
Thanks!
--
Best regards,
Sergey Urushkin
9 years, 5 months
sssd subprocess gets SIGKILL signal even after restart
by Daniel Jung
Hi,
I had reporeted while back indicating that sssd subprocess ldap and nss
stops working under heavy load. Looks like even after restart, its getting
SIGKILL.
Running on centos 6.5 and SSSD 1.9.2-129. I looked through the recent
release notes for 1.9. branch but wasn't sure if this has been
reported/fixed yet.
Could you please advise ?
Thanks
from sssd.log
Wed Oct 29 15:44:43:453121 2014) [sssd] [get_ping_config] (0x0100): Time
between service pings for [nss]: [10]
(Wed Oct 29 15:44:43:453191 2014) [sssd] [get_ping_config] (0x0100): Time
between SIGTERM and SIGKILL for [nss]: [60]
(Wed Oct 29 15:44:43:453206 2014) [sssd] [start_service] (0x0100): Queueing
service nss for startup
(Wed Oct 29 15:44:43:669185 2014) [sssd] [get_ping_config] (0x0100): Time
between service pings for [LDAP]: [10]
(Wed Oct 29 15:44:43:669300 2014) [sssd] [get_ping_config] (0x0100): Time
between SIGTERM and SIGKILL for [LDAP]: [60]
(Wed Oct 29 15:44:43:669332 2014) [sssd] [start_service] (0x0100): Queueing
service LDAP for startup
(Wed Oct 29 15:44:47:042335 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Entering.
(Wed Oct 29 15:44:48:769082 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Adding connection 0x69ae40.
(Wed Oct 29 15:44:49:704634 2014) [sssd] [sbus_init_connection] (0x0200):
Adding connection 69AE40
(Wed Oct 29 15:45:35:868409 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Got a connection
(Wed Oct 29 15:45:35:868510 2014) [sssd] [service_send_ping] (0x0100):
Pinging pam
(Wed Oct 29 15:45:35:868773 2014) [sssd] [get_ping_config] (0x0100): Time
between service pings for [nss]: [10]
(Wed Oct 29 15:45:35:868824 2014) [sssd] [get_ping_config] (0x0100): Time
between SIGTERM and SIGKILL for [nss]: [60]
(Wed Oct 29 15:45:35:868844 2014) [sssd] [start_service] (0x0100): Queueing
service nss for startup
(Wed Oct 29 15:45:35:869539 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Entering.
(Wed Oct 29 15:45:35:869580 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Adding connection 0x69c820.
(Wed Oct 29 15:45:35:869596 2014) [sssd] [sbus_init_connection] (0x0200):
Adding connection 69C820
(Wed Oct 29 15:45:35:869641 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Got a connection
(Wed Oct 29 15:45:35:869803 2014) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Wed Oct 29 15:45:38:543488 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Entering.
(Wed Oct 29 15:45:38:718699 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Adding connection 0x698910.
(Wed Oct 29 15:45:38:718740 2014) [sssd] [sbus_init_connection] (0x0200):
Adding connection 698910
(Wed Oct 29 15:45:38:718795 2014) [sssd] [sbus_server_init_new_connection]
(0x0200): Got a connection
(Wed Oct 29 15:45:45:006440 2014) [sssd] [service_send_ping] (0x0100):
Pinging pam
(Wed Oct 29 15:45:45:006711 2014) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Wed Oct 29 15:45:45:869420 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnecting 69AE40
(Wed Oct 29 15:45:45:869534 2014) [sssd]
[sbus_default_connection_destructor] (0x0200): Invoking default destructor
on connection 69AE40
(Wed Oct 29 15:45:45:869609 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnected 69AE40
(Wed Oct 29 15:45:45:870728 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnecting 69C820
(Wed Oct 29 15:45:45:870765 2014) [sssd]
[sbus_default_connection_destructor] (0x0200): Invoking default destructor
on connection 69C820
(Wed Oct 29 15:45:45:870802 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnected 69C820
(Wed Oct 29 15:45:48:721481 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnecting 698910
(Wed Oct 29 15:45:48:721584 2014) [sssd]
[sbus_default_connection_destructor] (0x0200): Invoking default destructor
on connection 698910
(Wed Oct 29 15:45:48:721669 2014) [sssd] [sbus_disconnect] (0x0200):
Disconnected 698910
from sssd-ldap.log
(Wed Oct 29 15:44:47:798536 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Entering.
(Wed Oct 29 15:44:47:798555 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Adding connection 0x6bb740.
(Wed Oct 29 15:44:47:798582 2014) [sssd[be[LDAP]]] [sbus_init_connection]
(0x0200): Adding connection 6BB740
(Wed Oct 29 15:44:47:798614 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Got a connection
(Wed Oct 29 15:44:50:226352 2014) [sssd[be[LDAP]]] [id_callback] (0x0010):
The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
(Wed Oct 29 15:45:36:489821 2014) [sssd[be[LDAP]]] [cleanup_users]
(0x0200): User mapred is still logged in or a dummy entry, keeping data
(Wed Oct 29 15:46:01:521917 2014) [sssd[be[LDAP]]]
[resolv_gethostbyname_next] (0x0200): No more address families to retry
(Wed Oct 29 15:46:01:534696 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Entering.
(Wed Oct 29 15:46:01:534727 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Adding connection 0x6f0420.
(Wed Oct 29 15:46:01:534740 2014) [sssd[be[LDAP]]] [sbus_init_connection]
(0x0200): Adding connection 6F0420
(Wed Oct 29 15:46:01:534763 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Got a connection
(Wed Oct 29 15:46:01:654795 2014) [sssd[be[LDAP]]]
[be_resolve_server_process] (0x0200): Found address for server server name:
TTL 3600
(Wed Oct 29 15:46:01:712980 2014) [sssd[be[LDAP]]] [get_naming_context]
(0x0200): Using value from [namingContexts] as naming context.
(Wed Oct 29 15:46:01:745392 2014) [sssd[be[LDAP]]]
[sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is
supported by this server!
(Wed Oct 29 15:46:01:745419 2014) [sssd[be[LDAP]]]
[sdap_get_server_opts_from_rootdse] (0x0200): Will use modification
timestamp as usn!
(Wed Oct 29 15:46:09:017362 2014) [sssd[be[LDAP]]] [init_timeout] (0x0040):
Client timed out before Identification [0x70fbf0]!
(Wed Oct 29 15:46:09:017415 2014) [sssd[be[LDAP]]] [sbus_disconnect]
(0x0200): Disconnecting 6F0420
(Wed Oct 29 15:46:09:017452 2014) [sssd[be[LDAP]]]
[sbus_default_connection_destructor] (0x0200): Invoking default destructor
on connection 6F0420
(Wed Oct 29 15:46:09:017510 2014) [sssd[be[LDAP]]] [sbus_disconnect]
(0x0200): Disconnected 6F0420
(Wed Oct 29 15:46:10:509589 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Entering.
(Wed Oct 29 15:46:10:509635 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Adding connection 0x6c7360.
(Wed Oct 29 15:46:10:509647 2014) [sssd[be[LDAP]]] [sbus_init_connection]
(0x0200): Adding connection 6C7360
(Wed Oct 29 15:46:10:509676 2014) [sssd[be[LDAP]]]
[sbus_server_init_new_connection] (0x0200): Got a connection
from messages
Oct 29 15:44:43 hostname sssd[nss]: Shutting down
Oct 29 15:44:43 hostname sssd[be[LDAP]]: Shutting down
Oct 29 15:44:46 hostname sssd[nss]: Starting up
Oct 29 15:44:46 hostname sssd[be[LDAP]]: Starting up
Oct 29 15:45:38 hostname sssd[nss]: Starting up
9 years, 5 months
Client randomly losing GID information on NFS files w/ 1.12.1
by Joschi Brauchle
Hello all,
I am experiencing strange behaviour of some of my NFS clients running
SSSD-AD 1.12.1. Some machines seem to be losing the 'group name <-> GID'
mapping on files on an NFS share, see this example:
---------------
$ l -d SOMEFOLDER
drwxrwxr-x 17 root 4294967294 4096 Nov 6 15:31 SOMEFOLDER/
$ stat SOMEFOLDER
File: ‘SOMEFOLDER’
Size: 4096 Blocks: 8 IO Block: 65536 directory
Device: 26h/38d Inode: 27258 Links: 17
Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: (4294967294/
UNKNOWN)
...
---------------
Also all files SOMEFOLDER/* are affected.
I know the group the folder is supposed to have is set correctly and
other clients show its name. Also, users who are in the missing group
show the groupname and GID just fine when doing an 'id USERNAME'.
Restarting SSSD resolves the issue for some time.
My SSSD config is as follows:
---------------
[sssd]
config_file_version = 2
services = nss,pam
domains = default
[nss]
filter_groups = root
filter_users = root
[pam]
[domain/default]
id_provider = ad
auth_provider = ad
access_provider = simple
chpass_provider = ad
ad_domain = ...
ad_enable_gc = False
ldap_id_mapping = False
enumerate = False
ignore_group_members = True
dyndns_update = False
cache_credentials = True
ldap_search_base = ...
ldap_user_search_base = ...
ldap_group_search_base = ...
ldap_user_search_scope = one
ldap_group_search_scope = one
krb5_ccachedir = /run/user/%U
krb5_ccname_template = DIR:%d/krb5cc
override_homedir = ...
simple_allow_groups = ...
---------------
Is this a known problem with 1.12.1?
I will test with 1.12.2 soon, but as the problem only appears randomly,
I thought I'd already ask now...
Best regards,
J Brauchle
9 years, 5 months
SSSD-AD and SSH GSSAPI problem - No key table entry found matching host
by crony
Hi All,
I have a properly functioning integration between RHEL6.6/Cento6.6 and
Active Directory 2008 using adcli tool and sssd-ad (
http://jhrozek.livejournal.com/3581.html):
# adcli join acme.example.com -U userdomain
# adcli info acme.example.com
[domain]
domain-name = acme.example.com
domain-short = ACME
domain-forest = example.com
domain-controller = dom1.acme.example.com
domain-controller-site = CENTRAL
domain-controller-flags = gc ldap ds kdc timeserv closest writable
full-secret ads-web
domain-controller-usable = yes
domain-controllers = dom1.acme.example.com dom2.acme.example.com
[computer]
computer-site = CENTRAL
The sssd.conf :
[sssd]
services = nss, pam, ssh
config_file_version = 2
domains = ACME.EXAMPLE.COM
debug_level = 7
[domain/ACME.EXAMPLE.COM]
krb5_use_enterprise_principal = false
krb5_realm = ACME.EXAMPLE.COM
ldap_force_upper_case_realm = true
ldap_account_expire_policy = ad
override_homedir = /home/%d/%u
ldap_id_mapping = true
subdomain_enumerate = true
ldap_schema = ad
ad_access_filter =
memberOf=CN=linuxgroup,OU=_Groups,DC=acme,DC=example,DC=com
ad_enable_gc = false
ldap_access_order = filter, expire
enumerate = false
id_provider = ad
auth_provider = ad
access_provider = ad
subdomains_provider = ad
chpass_provider = ad
ad_server = dom1.acme.example.com, dom2.acme.example.com
ad_domain = acme.example.com
ad_hostname = client1.acme.example.com
ad_enable_dns_sites = false
dyndns_update = false
debug_level = 7
/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 = acme.example.com
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
ignore_acceptor_hostname = true
[realms]
acme.example.com = {
kdc = acme.example.com
admin_server = acme.example.com
}
[domain_realm]
.acme.example.com = acme.example.com
acme.example.com = acme.example.com
.example.com = acme.example.com
example.com = acme.example.com
[appdefaults]
debug = true
I can log in with user/password from AD to RHEL/Centos, I can change the
password, lock the account from AD, etc. It all works.
The problem is within GSSAPI SSH-SSO Authentication. Simple, it doesnt
work. I see in logs:
Nov 4 16:36:42 ipatst02 sshd[4195]: debug1: Unspecified GSS failure.
Minor code may provide more information\nNo key table entry found matching
host/client1.acme.example.com@\n
Any idea what could be the reason? All I want to achieve is to get SSH-SSO
working, directly from AD desktop machine to Linux systems without password
prompt.
/lm
9 years, 5 months