Hi Team,
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?
Thanks

HI!
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.
Ciao, Michael.

i have sssd working with nss, pam, sudo and autofs against openldap and
mit kerberos, using the rfc2307 schema for posix account types. with
it, i am able to sudo without passwords as i have a sudoOption set to "!
authenticate".
i am building a new, parallel environment updated to use rfc2307bis, and
have sssd working with nss, pam, sudo and autofs, but when i attempt
sudo, i am prompted for my password. i have checked the sudoOption, and
it is set to "!authenticate". i am allowed to sudo if i enter my
password, but it seems the NOPASSWD equivalent is not being picked up
for some reason.
another interesting tidbit is that when i run "sudo -l" in the old
environment, the output ends with:
User brendan may run the following commands on desktop:
(ALL) NOPASSWD: ALL
when i run "sudo -l" in the new environment, the output ends with:
User brendan may run the following commands on server1:
(ALL) ALL
(ALL) ALL
(ALL) NOPASSWD: ALL
it seems to me that sudoHost, sudoCommand or some other objects are
causing conflict and something does not compute correctly. why are
there 3 lines of access rules, when only one exists for my ID.
oddly enough, i just found this behavior: when i first attempt to sudo,
i am prompted for my password. if i enter it, and gain sudo access, any
subsequent requests for sudo are not authenticated, per session. if i
logout/end my ssh session, and go back in i have to enter my password
once for sudo access and again subsequent sudo requests do not prompt
for a password.
is there a setting that i need to change other than ldap_schema? the
ldap_sudo_search_base is set to the correct location in the directory,
since i am not using the default.
selinux is disabled
my sssd.conf
------------
[sssd]
domains = bpk2.com
services = nss, pam, sudo, autofs
config_file_version = 2
#debug_level = 4
[nss]
filter_groups = root
filter_users = root
[pam]
[sudo]
[autofs]
[domain/bpk2.com]
#debug_level = 4
id_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
ldap_search_base = dc=bpk2,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/server1.bpk2.com
ldap_sasl_realm = BPK2.COM
auth_provider = krb5
krb5_server = _srv_,kerberos.bpk2.com
krb5_realm = BPK2.COM
krb5_renewable_lifetime = 7d
krb5_lifetime = 24h
krb5_renew_interval = 1h
krb5_store_password_if_offline = true
cache_credentials = true
sudo_provider = ldap
ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
#ldap_sudo_full_refresh_interval = 86400
#ldap_sudo_smart_refresh_interval = 3600
autofs_provider = ldap
ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,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
#min_id = 1000
#max_id = 2000
enumerate = false
/var/log/sssd/sssd_nss.log contains some lines:
(Sun Dec 21 12:02:58 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 12:07:59 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:19:33 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:21:36 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:21:51 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:22:09 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:22:30 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:22:45 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:23:21 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:23:41 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:29:53 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:31:42 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
(Sun Dec 21 13:32:09 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
(0x0010): getgrgid call returned more than one result !?!
i am also seeing in /var/log/sssd/sssd_bpk2.com.log:
(Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [load_backend_module]
(0x0010): Error (22) in module (ldap) initialization
(sssm_ldap_sudo_init)!
(Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [be_process_init]
(0x0010): fatal error initializing data providers
(Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [main] (0x0010): Could
not initialize backend [22]

=== SSSD 1.9.7 ===
The SSSD team is proud to announce the release of version 1.9.7 of
the System Security Services Daemon.
Most importantly, SSSD 1.9.7 is the last planned release of the LTM
sssd-1-9 branch. User of SSSD 1.9.x are advised to upgrade to SSSD 1.11.x
which will become the next LTM version. Another 1.9.x tarball would only
be released in case of a critical security issue or a regression caused
by the patches in 1.9.7.
As always, the source is available from https://fedorahosted.org/sssd
This is a bugfix release with a minor feature enhancement -- see
the changelog below for details.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-develhttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
== Highlights ==
* This release is the last supported upstream release in the 1.9.x
series. Users of sssd-1.9 are advised to upgrade to sssd-1.11
* A memory leak in the netgroup code of the NSS responder was fixed
* Subdomains inherit min_id/max_id limits of parent domains. The user-visible
effect of this bug was that adding system users or groups with shadow-utils
took too long.
* The default_domain_suffix is ignored in the autofs responder, making it
possible to use default_domain_suffix along with autofs integration
* Several fixes related to Kerberos DIR cache support were backported from
later releases
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/1936
GSSAPI working only on first login
https://fedorahosted.org/sssd/ticket/2153
If both IPA and LDAP are set up with enumeration on, two enum
tasks are running
https://fedorahosted.org/sssd/ticket/2170
sssd_nss grows memory footprint when netgroups are requested
https://fedorahosted.org/sssd/ticket/2157
sssd_be segfaults if empty grop is resolved using ad_matching_rule
https://fedorahosted.org/sssd/ticket/2077
[RFE] If originalDN is not available during LDAP auth, the SSSD
should look it up
https://fedorahosted.org/sssd/ticket/2051
Do not fail if initgroups returns NOT_FOUND
https://fedorahosted.org/sssd/ticket/2123
Creating system accounts on a IdM client takes up to 10 minutes
when AD trust is configured in the IdM.
== Detailed Changelog ==
Aron Parsons (1):
* do not use default_domain_suffix with autofs
Jakub Hrozek (7):
* Bumping the version for 1.9.7
* Inherit ID limits of parent domains if set
* PROXY: Handle empty GECOS
* LDAP: Split out a request to search for a user w/o saving
* LDAP: Search for original DN during auth if it's missing
* LDAP: Initialize user count for AD matching rule
* Updating translations for the 1.9.7 release
Lukas Slebodnik (6):
* NSS: Fix memory leak in sss_setnetgrent
* AUTOTOOLS: krb5 1.12 is also supported krb5 libs
* LDAP: Setup periodic task only once.
* Fix wrong detection of krb5 ccname
* Every time return directory for krb5 cache collection.
* Do not switch to credentials everytime.
Simo Sorce (1):
* proxy: Allow initgroup to return NOTFOUND

Hi guys (and girls if any)...
First of all - great piece of software. Merging the worlds of Linux and
Windows got pretty simple and advanced as well.
I've got sssd 1.11.6 on a CentOS 6.6 test box talking to AD on a Windows
2008R2. Password and public key auth are working almost out of the box.
Since I would like to restrict SSH access to my boxes, I discovered the
"ad_access_filter" and added a simple
ad_access_filter =
memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local
"Unfortunately" I have nested groups and in the group called
"permunix.adm.tvie02s010" there is another group that holds my admins -
called "permunix.adm.admins". Since there is a group in a group I could not
get any results that would match my user that is in the group "..admins".
When I do a simple id -a username, I get the both groups for my admin user.
But the login via SSH would fail with ...
[sdap_process_result] (0x2000): Trace: ldap_result found nothing!
My domain portion of sssd.conf looks like this:
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_search_base = dc=my01,dc=local
ldap_id_mapping = false
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_schema = ad
cache_credentials = false
ldap_user_ssh_public_key = extensionAttribute15
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = TVIE02S010$
ldap_krb5_keytab = /etc/krb5.keytab
ldap_krb5_init_creds = true
ldap_krb5_ticket_lifetime = 28800
ldap_groups_use_matching_rule_in_chain = true
ldap_initgroups_use_matching_rule_in_chain = true
ldap_use_tokengroups = false
ldap_group_nesting_level = 5
debug_level = 9
ad_access_filter =
memberOf=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local
Any ideas why the LDAP_MATCHING_RULE_IN_CHAIN doesn't resolve the group
members?
When I use a simple ldapsearch on the console with
(&(sAMAccountName=myusername)(objectclass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=permunix.adm.tvie02s010,ou=permunix,ou=groups,ou=adm,dc=my01,dc=local))
I get one result with my user object... Since you parse the
ad_access_filter I cannot enter the LDAP_MATCHING_RULE_IN_CHAIN OID in the
filter itself.
Thank you in advance!

> Sorry for the blind email, but we are hitting a wall. We currently use
> ODSEE LDAP for OS auth services. With the migration to sssd we are
> noticing that connection time takes an unacceptable amount of time. We
> have done some debugging and notice that SSSD pulls all of the users
> POSIX object class attributes from LDAP. We use host attributes to
> granularly regulated who can log in where. With some users having 10K
> host attributes, it takes a while for sssd to import and cache all
> that information. If there anyway to stop SSSD from caching all the
> users info? Maybe just the uid, passwd and shadow?