UID Auto-increment reset
by Lesley Kimmel
I noticed that when I create a user in the local provider with sss_useradd that the uid's begin at 1000 (or the next available based on current local users in /etc/passwd) and they increment each time as expected. However, if I add a user with sss_useradd and then immediately delete him the next created user still uses the next higher UID instead of the one freed up from the previous user. This still happens if I clear all sssd cache. Is there a way to reset this counter without explicitly specifying the UID with '-u'?
7 years, 4 months
UID < 1000 Configurable?
by Lesley Kimmel
I was just playing with the sssd local provider and attempting to create a user like 'sss_useradd -u 999 <username>' and I get the error 'The selected UID is outside the allowed range'. Setting UID_MIN in sssd.conf and/or login.defs does not seem to help. Is this a hard-coded limitation?
7 years, 4 months
sssd monitor_quit_signal - causes? No matching domain found for [root], fail!
by Richard Collins
Running Red Hat Enterprise Linux Server release 6.5 (Santiago) - 2.6.32-431.el6.x86_64
SSSD version: sssd-1.13.3-22.el6_8.4.x86_64
I'm seeing (seemingly random?) shutdown/termination of sssd across multiple nodes, all with the same configuration. To my knowledge there is no process going around killing things, we even have a scheduled job to check sssd status and restart every 5 minutes if unavailable:
/var/log/sssd/sssd.log:284469:(Mon Sep 26 12:21:29 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command
/var/log/sssd/sssd.log:318707:(Mon Sep 26 16:19:19 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command
/var/log/sssd/sssd.log:321889:(Mon Sep 26 16:43:12 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command
/var/log/sssd/sssd.log:474327:(Tue Sep 27 10:29:39 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command
/var/log/sssd/sssd.log:475205:(Tue Sep 27 10:34:36 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command
Right before each shutdown, there are lots of the following nss_cmd_getbynam and sss_ncache_check_str entries for 'root' in sssd_nss.log:
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [38][SSS_NSS_INITGR] with input [root].
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [root] from [<ALL>]
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/MYDOMAIN/root]
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [nss_cmd_initgroups_search] (0x0400): User [root] does not exist in [MYDOMAIN]! (negative cache)
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [nss_cmd_initgroups_search] (0x0080): No matching domain found for [root], fail!
(Mon Sep 26 16:43:11 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0xf7e120][24]
(Mon Sep 26 16:43:12 2016) [sssd[nss]] [sss_responder_ctx_destructor] (0x0400): Responder is being shut down
(Mon Sep 26 16:43:12 2016) [sssd[nss]] [client_destructor] (0x2000): Terminated client [0xf7e120][24]
(Mon Sep 26 16:43:12 2016) [sssd[nss]] [client_destructor] (0x2000): Terminated client [0xf840e0][23]
(Mon Sep 26 16:43:12 2016) [sssd[nss]] [client_destructor] (0x2000): Terminated client [0xf7b500][22]
Corresponding AD log for same period:
(Mon Sep 26 16:43:10 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): dbus conn: 0x142aa90
(Mon Sep 26 16:43:10 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Sep 26 16:43:10 2016) [sssd[be[MYDOMAIN]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service
(Mon Sep 26 16:43:10 2016) [sssd[be[MYDOMAIN]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x1440c50/0x143e080
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x1440c50/0x143e030
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): dbus conn: 0x143eb00
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [be_client_destructor] (0x0400): Removed SUDO client
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x1444030/0x14420b0
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x1444030/0x1442060
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): dbus conn: 0x1443250
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [be_client_destructor] (0x0400): Removed PAM client
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x143d070/0x142c0d0
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x143d070/0x142aeb0
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): dbus conn: 0x143c570
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [be_client_destructor] (0x0400): Removed NSS client
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [be_ptask_destructor] (0x0400): Terminating periodic task [SUDO Smart Refresh]
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [be_ptask_destructor] (0x0400): Terminating periodic task [SUDO Full Refresh]
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sdap_handle_release] (0x2000): Trace: sh[0x14f9ff0], connected[1], ops[(nil)], ldap[0x1449c10], destructor_lock[0], release_memory[0]
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [remove_connection_callback] (0x4000): Successfully removed connection callback.
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [sbus_remove_watch] (0x2000): 0x142f250/0x1417480
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [remove_socket_symlink] (0x4000): The symlink points to [/var/lib/sss/pipes/private/sbus-dp_MYDOMAIN.11328]
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [remove_socket_symlink] (0x4000): The path including our pid is [/var/lib/sss/pipes/private/sbus-dp_MYDOMAIN.11328]
(Mon Sep 26 16:43:12 2016) [sssd[be[MYDOMAIN]]] [remove_socket_symlink] (0x4000): Removed the symlink
AD controllers are WIN2012R2
SSSD is configured with a single domain (MYDOMAIN)
######begin sssd.conf (redacted)#####
[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=mydomain
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, 4 months
UIDs and GIDs closely to the max range available
by mg_gonzalez8＠hotmail.com
Hi all, thanks for your time. I have a question regarding to the 'ldap_idmap_range_max = 2000100000'. I have users with UIDs and GIDs closely to the max range available. How I can prevent to maintain under this max range? or There's any other solution to restrict the sssd configuration to only retrieve users and groups from an AD ?.
I already tried with "ad_access_filter = (memberOf=cn=admins,ou=Testou,dc=example,dc=com)".
(Ubuntu 14.04 LTS)
7 years, 4 months
SSH AuthorizedKeysCommand and SSSD default_domain_suffix
by Troels Hansen
Hi there
After default_domain_suffix finally began working corretly in SSSD 1.14 we have started using it, but have found a side affect og not logging in with full domain:
We currently have some AD domain users having a override on out IPA servers, where they have added their SSH key.
If AuthorizedKeysCommand is set to sss_ssh_authorizedkeys in SSH without a domain (-d) it will not try to look up the users SSH key
I would suppose that sss_ssh_authorizedkeys should at least try to look up the user with the default_domain_suffix from sssd.conf?
Even better would probably be to implement a fallback to try both the configured ipa_domain and default_domain_suffix?
--
Med venlig hilsen
Troels Hansen
Systemkonsulent
Casalogic A/S
T (+45) 70 20 10 63
M (+45) 22 43 71 57
Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere.
7 years, 4 months
sssd simple_allow_groups & ad not working
by brettswift＠gmail.com
RHEL 6.4
sssd v1.11.6
Preface : I'm just recently absorbing sssd so I might be missing something here. I assume that you can use the simple access provider with the ad id_provider.
In my domain section:
cache_credentials = true
id_provider = ad
auth_provider = ad
access_provider = simple
default_shell = /bin/bash
fallback_homedir = /home/%u
use_fully_qualified_names = false
ignore_group_members = true
And below I've tried a few things in the domain section:
simple_allow_users = bswift ---> this works!
simple_allow_groups = sjrb.lg.it.cfg.cdo --> this doesn't work :(
I'd really prefer to use the simple provider as it's just easier to configure. We are using puppet as our config management tool so non-admins could submit pull requests via git and they'd only have to know a simpler user API, and not understand SSSD or LDAP queries.
Is this a deficiency in the version I'm using?
I found a post on this forum where setting "ldap_use_tokengroups = false" might help, tried that.. didn't help.
debug_level = 7 gives me this log output (just the last few lines)
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists] (0x0200): Allow users list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists] (0x0200): Deny users list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists] (0x0200): Deny groups list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_check_send] (0x0200): Simple access check for bswift
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x1000): Looking up groups for user bswift
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x0400): User bswift is a member of 74 supplemental groups
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x0400): All groups had name attribute
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_check_recv] (0x1000): Access not granted
One thing that may be causing this is in AD under this group name, I see this:
"To enable access to this group for UNIX clients you will need to specify the NIS domain this group belongs to." However the dropdown is empty (maybe access rights as I'm not the domain admin).
Sometimes what you read on a windows box isn't the full truth.. maybe it is in this case?
Any direction here would be appreciated.
Thanks!
7 years, 4 months
Question about AD authentication and trusts
by Guy Knights
Hi,
Can anyone confirm for me if SSSD supports authentication of users
belonging to a trusted domain via an AD controller in the trusting domain?
ie. A user attempts to log in as fred(a)test1.example.com on a client machine
running SSSD, where SSSD has joined a domain test2.example.com and there is
a 2-way forest trust between both domains. Is this supported? I've been
trying to do so and so far it hasn't been working.
For the record, my setup is:
AD controller domain test1: Windows server 2012 R2
AD controller domain test2: Windows server 2012 R2
Ubuntu 14.04 client running SSSD 1.12.5
Thanks,
Guy
7 years, 5 months
Only one (main) group listed for users
by gstaniak＠gmail.com
Hi,
I've been trying to set up a Fedora 24 Linux notebook to integrate with company AD using realmd+sssd. The sssd.conf is pretty simple:
[pam]
offline_credentials_expiration = 31
debug_level = 6
[sssd]
domains = the.domain
config_file_version = 2
services = nss, pam
debug_level = 6
[domain/the.domain]
ad_domain = the.domain
krb5_realm = THE.DOMAIN
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
ldap_schema = rfc2307bis
#ldap_group_member = uniqueMember
debug_level = 6
enumerate = true
I joined the realm/AD without any problems, but when I log in as an AD user, running 'id' and 'groups' lists just one (main) group for my user. However, when I run the command 'id <username>' and 'groups <username>' from the root account OR a local user account, all groups that the <username> belongs to are listed. I suspected local group membership, so I added the AD user to the same groups as the local user, but that didn't improve the situation.
After I tried to add the "ldap_group_option" (commented out above), purged the cache and restart sssd, I lost the group listings even from the root and local account: they all now list just the highest level "domain users" group for the user in 'id' and 'groups' output, and instead of a long list of names as the result of 'getent group domain\ users' all I get now is:
# getent group domain\ users
domain users:*:1763200513:$d3f33f9-6c0c33b5b410283,$bfb716e9-67211aebe1652897,$f45c71f7-5ed7e3c5d1020d99
What could be the reason for this? How can I debug the issue?
Thanks,
Greg
7 years, 5 months
I have no name prompt and no passwords recognized
by Ronny Forberger
Hi,
I am using SSSD and FreeBSD to authenticate against samba4.
I used this howto setting all up:
http://serverfault.com/questions/599200/how-to-integrate-active-directory...
But when I want to logon using password, i.e. via dovecot I get wrong password.
Neigher can I use sudo typing the correct samba4 password.
Also I get a prompt [I have no name!@HOSTNAME] and my files, which I chowned &
chgrped to the samba user and group only show IDs as owner.
I have already asked on the FreeBSD maillinglist, but they couldn't help me.
Any ideas how to solve this? Can this maybe be a permission problem with some
file for sssd / NSS which an unprivileged user cannot read?
I have set UNIX attributes on the user I want to logon with.
Best regards,
Ronny Forberger
7 years, 5 months
sssd cannot modify the mtime of krb5.conf
by Ronny Forberger
Hi,
I get the following error on sssd on FreeBSD:
(Fri Nov 11 18:15:36 2016) [sssd[be[ronnyforberger.de]]] [sss_krb5_touch_config] (0x0020):
Unable to change mtime of "${prefix}/etc/krb5.conf" [2]: No such file or
directory
(Fri Nov 11 18:15:36 2016) [sssd[be[ronnyforberger.de]]] [sss_write_domain_mappings]
(0x0020): Unable to change last modification time of krb5.conf. Created mappings may not
be loaded.
The krb5.conf is owned and writeable by root and sssd also runs as root.
What can be the problem?
Best regards,
Ronny
7 years, 5 months
