i have two forests both working fine in terms of authentication.
I added a user to sudoers from one of the domains and he is getting access denied.
the user is able to login with no problem, sudo is not working.
in the secure log it shows "account is expired"
in the SSSD logs it shows error
"attempting to kinit for realm xxxxxx" then
"clients credentials has been revoked"
i checked the account and it is not expired nor locked.
additionally: I have another account on the same forest which i used to join to the domain and it is working fine on both authentication and sudoers.
I also tried ldap_user_principal = no suchattribute and krb5_use_enterprise_principal = false
but the problem remains.
what could be the reason behind being able to access and later getting clients credential revoked for sudoes?
I've been investigating problems with the SSSD 1.11 versions supplied in
RHEL/CentOS 6.6 for a while now. I've followed:
and also created a case with Red Hat support. However, I'm still no closer
to solving the issue.
After updating servers to the SSSD in 6.6, intermittently (for particular
users but not on all servers, and not necessarily all the time) users don't
get their supplementary groups. e.g:
[root@rhel6-template sssd]# id matthewbe
uid=46721(matthewbe) gid=20513(domain users) groups=20513(domain users)
This is with the latest SSSD on a RHEL6.6 server, i.e.:
Our environment is Windows 2003 AD controllers, and users *without* POSIX
attributes in their AD records. So, snippets of sanitised sssd.conf:
debug_level = 9
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ad_server = dc01.local,dc02.local
ad_backup_server = ad.local
ad_domain = ad.local
# ID mapping
min_id = 20000
ldap_idmap_range_min = 20000
#ldap_idmap_range_max = 220000
ldap_idmap_range_size = 200000
ldap_idmap_default_domain_sid = S-1-5-21-2365159532-2245169678-2931239768
ldap_schema = ad
ldap_id_mapping = true
override_homedir = /home/AD/%u
override_shell = /bin/bash
# access controls
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_referrals = false
I've tried a few config changes to fix the issue, but none has fixed it,
ldap_use_tokengroups = False
ldap_group_objectsid = objectSID
ldap_user_objectsid = objectSID
ldap_deref_threshold = 0
ldap_schema = rfc2307bis
Given Red Hat support hasn't been able to fix our issue, what else can I do?
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with
StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet)
and I'd like to let the sssd instances on all the systems authenticate to the
LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid
having to set/configure passwords for each system's sssd.
We have setup FreeIPA (VERSION: 4.1.2, API_VERSION: 2.109) in our realm (IPA.DOMAIN1.COM), with trust to an AD forest (DOMAIN2.NET, which itself has trust to AD.DOMAIN2.NET, where the corporate users are). Everything works fine when using Kerberos, we can obtain tickets from AD.DOMAIN2.NET and authenticate to services in IPA.DOMAIN1.COM. We can also do "getent passwd user(a)ad.domain2.net" on a host enrolled in FreeIPA and quickly get a result.
But we have some legacy applications that perform authentication with simple LDAP binds, so we have the compat tree enabled, and while trying to authenticate users in the AD.DOMAIN2.NET realm this way eventually succeeds, it takes an awfully long time (30 seconds or so, sometimes more), with a lot going on between the AD and FreeIPA. We've attached the log file of SSSD (version 1.12.4, we've upgraded based on advice from IRC #sssd, but the problem didn't go away) from the FreeIPA server while running "ldapwhoami -D uid=user(a)ad.domain2.net,cn=users,cn=compat,dc=ipa,dc=domain1,dc=com -W" from a client machine. The debug level was set to 0x07f0.
On (rare) occasions, authentication is very fast while running the exact same command on the client machine. We've also attached the SSSD log file when that happens, for comparison. The log files have been sanitized and the slow log output was bit simplified, we removed 25 repeated events where sssd was trying to resolve unknown SIDs, it would have taken too much time to sanitize so we left 5 caching events only (we made a remark on the log file where we removed those lines.)
Any advice is more than welcome.
Thanks for your help.
Senior System Administrator - R&D and ops Infrastructure
Kudelski Security - Kudelski Group
rte de Genève 22-24, 1033 Cheseaux, SWITZERLAND
+41 21 732 03 79
We have a problem with the way SSSD tries to find out where to send DDNS updates. The problem is that SSSD doesn't use DNS to find the authoritative name server for a given zone, but assume that it must be the Active Directory Domain Controller to which it is connected.
In our case this is not correct in any way.
Our DNS setup is like this:
DNS-PTR.example.com is Authoritative for all our DNS PTR/reverse records (xxx.in-addr.arpa) and for the forward zone example.com with the exception of local.example.com (and subdomains), which is delegated to localserver1.local.example.com.
(This is purely internal - external we have another DNS service let's call it DNS-external.example.com, but it doesn't matter in this example/problem).
Our Active directory is a forrest named local.example.com with subdomains a.local.example.com, b.local.example.com, etc. each Active directory subdomain has it's own domain controllers let's say localserverA.a.local.example.com, localserverB.b.local.example.com, etc.
Active Directory computer objects (accounts) are located in sub-domains ex. nfsserverA.a.local.example.com, nfsclientB.b.local.example.com, etc.
Just for your information: Active Directory user objects (accounts) are located in all Active Directory domains - including top domain local.example.com.
When nfsserverA.a.local.example.com is trying to update it's DNS record it's sending the update to the Active Directory Domain Controller localserverA.a.local.example.com, which is only running Active Directory Services (Domain Controller, Global Catalog, etc.) and not a DNS service, because it assumes that the Active Directory Domain Controller also is running DNS service.
If SSSD had done a DNS lookup for the DNS Name Server record for a.local.example.com it's told that the DNS Name Server is localserver1.local.example.com. And if it's looking for the responsible DNS name server for the reverse zone x.y.10.in-addr.arpa. (we are running 10.0.0.0/8 divided into /24 subnets as our internal IP subnets) it's told to that the responsible server is DNS-PTR.example.com (only accessible from our internal network).
PS: I have seen the comments in https://lists.fedorahosted.org/pipermail/sssd-users/2014-June/001878.html talking about creating an option in sssd.conf called something like fallback_dns_master, but I find that very inflexible and not the right way to go ... because, if we move the DNS service form one server to another we'll have to change a lot of local client configuration. Another argument is that we actually have multiple servers authoritative for local.example.com and I suppose that it's only possible to configure one server in the suggested attribute "fallback_dns_master".
> Message: 1
> Date: Thu, 12 Feb 2015 21:22:14 +0100
> From: Jakub Hrozek <jhrozek(a)redhat.com>
> To: sssd-users(a)lists.fedorahosted.org
> Subject: Re: [SSSD-users] Integration with Samba 4 using POSIX
> Message-ID: <20150212202214.GR2917(a)hendrix.brq.redhat.com>
> Content-Type: text/plain; charset=us-ascii
> On Thu, Feb 12, 2015 at 01:12:52PM -0700, Wayne Andersen wrote:
> > I have sssd 1.11.6 installed and without ldap_id_mapping=false
> > everything works great.
> > If I want to use POSIX attributes and I do sssd fails:
> > (Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]]
> > [load_backend_module] (0x0010): Error (5) in module (ad)
> > initialization (sssm_ad_id_init)!
> > (Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]]
> > [be_process_init]
> > (0x0010): fatal error initializing data providers
> > (Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]] [main]
> > Could not initialize backend 
> Does it help to remove the cache (rm -f /var/lib/sss/db/cache_*.ldb)
> If not, can you raise debug_level, restart SSSD and paste more context from
> the logs?
Yes, that fixed it.
=== SSSD 1.12.4 ===
The SSSD team is proud to announce the release of version 1.12.4 of
the System Security Services Daemon.
As always, the source is available from https://fedorahosted.org/sssd
RPM packages will be made available for Fedora 21, 22 and rawhide shortly.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
== Highlights ==
* This is mostly a bug fixing release with only minor enhancements visible
to the end user
* Contains many fixes and enhancements related to the ID views functionality
of FreeIPA servers
* Several fixes related to retrieving AD group membership in an IPA-AD
* Fixes a bug where the GPO access control previously didn't work at all
if debugging was enabled in smb.conf.
* SSSD can now be pinned to a particular AD site instead of autodiscovering
* A regression that caused setting the SELinux context for IPA users to
fail, was fixed
* Fixed a potential crash caused by a double-free error when an SSSD
service was killed by the monitor process
== Packaging Changes ==
* Several patches that allow building the Python code in SSSD with python3
== Documentation Changes ==
* A new option ad_site was added. When this option is set, SSSD will
attempt to connect to DCs from this particular AD site instead of looking
up the site via DNS
* The ad_gpo_map_permit option now also includes the systemd-user service
to avoid errors in processing of the PAM session stack
== Tickets Fixed ==
Make return codes of basic sysdb operations consistent
Write message to syslog about users with duplicated UID
Investigate Kerberized NFS4 setup with the new NFS plugin
[RFE] ad provider dns_discovery_domain option: kerberos discovery is not using this option
sssd-ad: The man page description to enable GPO HBAC Policies are unclear
Monitor SIGKILL timer issue and service restart failure
sssd.conf(5) man page gives bad advice about domains parameter
sssd_be crashes in nested LDAP code with a use-after-free error
GPO offline processing rejects access if no applicable GPOs are find in the cache
GPO code fails if no LDAP URI can be resolved
GPO: libsmbclient logs to stdout by default, cluttering gpo_child output
gzip: stdin: file size changed while zipping when rotating logfile
Document that dyndns_iface only supports a single interface
libsss_simpleifp should pull sssd-dbus
add systemd-user to default gpo list
pam_sss(sshd:auth): authentication failure with user from AD
PAC responder is called after krb5_child switches to the user logging in
Users saved throug extop don't have the originalMemberOf attribute
Need to set different umask in selinux_child
selinux_child needs to setuid(0) to make libselinux work as non-root
Uncached SIDs cannot be resolved
Same member saved as ghost and as member in IPA server mode
IPA initgroups don't work correctly in non-default view
[abrt] sssd-common: talloc_abort(): sssd killed by SIGABRT
user_attributes missing from ifp schema
== Detailed Changelog ==
Bohuslav Kabrda (1):
* Python3 support in SSSD
Jakub Hrozek (23):
* Updating the version to the 1.12.4 release
* GPO: Ignore ENOENT result from sysdb_gpo_get_gpo_result_setting()
* TESTS: Cover sysdb_gpo.c with unit tests
* GPO: Set libsmb debugging to stderr
* UTIL: Allow dup-ing child pipe to a different FD
* GPO: Don't use stdout for output in gpo_child
* GPO: Extract server hostname after connecting
* krb5_child: Return ERR_NETWORK_IO on KRB5_KDCREP_SKEW
* Open the PAC socket from krb5_child before dropping root
* IPA: Use attr's dom for users, too
* SELINUX: Call setuid(0)/setgid(0) to also set the real IDs to root
* SELINUX: Set and reset umask when caling set_seuser from deamon code
* LDAP: Add UUID when saving incomplete groups
* IPA: Resolve IPA user groups' overrideDN in non-default view
* LDAP: Rename the _res output parameter to avoid clashing with libresolv in tests
* RESOLV: Add an internal function to read TTL from a DNS packet
* resolv: Fix a typo
* SELINUX: Check the return value of setuid and setgid
* BUILD: Include python-test.py in the tarball
* GPO: Better debugging for gpo_child's mkdir
* LDAP: Add better DEBUG messages to the cleanup task
* LDAP: Handle ENOENT better in the cleanup task
* Updating translations for the 1.12.4 release
Lukas Slebodnik (11):
* logrotate: Fix warning file size changed while zipping
* PROXY: Fix use after free
* pysss: Fix double free
* MONITOR: Fix double free
* SSSDConfig: Remove unused exception name
* SSSDConfig: Port missing parts to python3
* Remove strict requirements of python2
* sbus_codegen: Port to python3
* Add missing new lines to debug messages
* CONFIGURE: Do not use macro AC_PROG_MKDIR_P twice
* RESPONDERS: Warn to syslog about colliding objects
Pavel Březina (1):
* spec: sifp requires sssd-dbus
Pavel Reichl (6):
* GPO: add systemd-user to gpo default permit list
* MAN: dyndns_iface supports only one interface
* MAN: add dots as valid character in domain names
* AD: add new option ad_site
* AD: support for AD site override
* MAN: amend sss_ssh_authorizedkeys
Rob Crittenden (1):
* Add user_attributes to ifp section of API schema
Sumit Bose (24):
* IPA: add get_be_acct_req_for_user_name()
* IPA: resolve ghost members if a non-default view is applied
* sysdb: fix group members with overridden names
* IPA: ipa_resolve_user_list_send() take care of overrides
* IPA: do not look up overrides on client with default view
* IPA: make version check more precise
* IPA: add missing break
* IPA: process_members() optionally return missing members list
* IPA: rename ipa_s2n_get_groups_send() to ipa_s2n_get_fqlist_send()
* IPA: resolve missing members
* IPA: set SYSDB_INITGR_EXPIRE for RESP_USER_GROUPLIST
* krb5: fix entry order in MEMORY keytab
* nss: make fill_orig() multi-value aware
* nss: refactor fill_orig()
* nss: Add original DN and memberOf to origbyname request
* views: fix GID overrride for mpg domains
* IPA: properly handle mixed-case trusted domains
* nss: fix SID lookups
* sysdb: remove ghosts in all sub-domains as well
* IPA: resolve IPA group-memberships for AD users
* IPA: process_members() add ghosts only once
* ipa_s2n_save_objects: properly handle fully-qualified group names
* AD: use GC for SID requests as well
* fill_id() fix LE/BE issue with wrong data type
I have sssd 1.11.6 installed and without ldap_id_mapping=false everything
If I want to use POSIX attributes and I do sssd fails:
(Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]]
[load_backend_module] (0x0010): Error (5) in module (ad) initialization
(Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]] [be_process_init]
(0x0010): fatal error initializing data providers
(Thu Feb 12 12:46:27 2015) [sssd[be[corp.clima-tech.com]]] [main] (0x0010):
Could not initialize backend 
services = nss, pam
config_file_version = 2
domains = corp.clima-tech.com
# Using id_provider=ad sets the best defaults on its own
id_provider = ad
# In sssd, the default access provider is always 'permit'. The AD access
# provider by default checks for account expiration
access_provider = ad
# Uncomment to use POSIX attributes on the server
# location of the keytab
#ldap_referrals = false
Wbinfo properly returns the posix attributes.
I've been playing around with sssd for a while not and it's been great but I've just run into a really weird problem. If I have a user specified in the 'simple_allow_users' configuration directive it works absolutely fine BUT I've got (at least) 2 groups that, for some reason, if the user is a member of these groups the account can't authenticate on my boxes. The groups that I'm having problems with are nothing to do with any simple_allow_groups - they're just normal AD security groups...
Can someone please point me in the right direction on this one or let me know how I can best find out why these groups are affecting sssd? I've been trawling logs but can't seem to find anything obvious.