Patch 0001: AD: Clean up ad_access_gpo
Just a minor cleanup to ad_gpo_access_send to adhere to our tevent
conventions. This is purely for aesthetic and maintainability reasons;
it has no functional effect.
Patch 0002: AD: Always get domain-specific ID connection
This one is a little tricky. It turns out that in some circumstances,
ad_ctx->ldap_ctx may actually be pointing at a subdomain rather than
the enrolled domain. I don't know the reasons for this (and it appears
to be a race-condition, because I could only get it to happen if I was
quick to test logins right after restarting SSSD). However, the fix is
fairly straightforward: sdap_domain_get()->pvt->ldap_ctx always
provides the real ldap_ctx for the requested domain (either the
enrolled domain or any of the trusted domains). The IS_SUBDOMAIN()
check and shortcut to ad_ctx->ldap_ctx was unnecessary and (thanks to
the odd race) incorrect. This patch removes this conditional shortcut
and forces us to get the correct ldap_ctx. This proved to be the last
piece necessary to get Patch 0003 to work.
Patch 0003: AD GPO: Always look up GPOs from machine domain
When dealing with users from a child domain, SSSD was attempting to use
the subdomain for lookups. However, all GPOs applicable to this machine
are stored in the primary domain (the domain the host directly joined).
This patch has the GPO processing use the primary domain instead of the
I saw couple of discussion around in this list as well as others
about how to exploit ppolicy with ssh : here are some thought.
Currently, I am in a situation where I have inserted my users
public ssh keys in ldap (openssh-ldappubkey shema) and
instructed sshd to consult ldap for ssh public keys, adding in
I also have authorized password authentication , in ssh_config:
My current policy is the following :
- All my users must have a password in ldap (that is used by
applications other than ssh)
- not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I now want to introduce ppolicy overlay and would like to enforce
rules for password management even for users that mainly use
Practically and basically : when a user with valid ssh key ask for
an ssh connexion, I would like ssh to behave exactly as if this user
had typed a correct "loging/password" and therefore check for
ppolicy situation before granting access.
- if the account is 'ppolicy desactivated', ssh would refuse to
provide the session
- if the password is "ppolicy oudated", then ssh would warn to
change it (and decrease 'pwdGraceAuthnLimit*'*?)
... and so on.
I thought about two options/alternatives to do that :
* try to tune pam (may be there would be a way to tell pam to check
for user ppolicy fields once authentication has been done before
granting access ?)
* add some sort of flag (aka: --ppolicy) to sss_ssh_authorizedkeys
to instruct sss_ssh_authorizedkeys to check for user ppolicy (use
'ldap_default_bind_dn' as a binding user) and if there is an issue
return a "ppolicy error message" rather than the user ssh key ?
These are just some thoughts.
I'm currently exploring the first option (but I'm not a 'pam' expert and
I'm even not sure that the ssh authentication process goes through
pam if a valid key is found, even with 'UsePAM yes').
I would appreciate any guidance, advices or experiences from you
on that particular issue.
the attached patches fix ticket
It turns out that calling libsemanage transactions is a fairly intensive
operation that involves copying multiple files under the /etc/selinux
hierarchy to a temporary subtree and then back. With the patches, the
context from IPA is checked against the local database first and only
applied if it differs.
sssd_sudo always asks for sudo rules for users specified in filter_users directive and creates large amount of traffic to LDAP servers. Proposed patch for this is attached (tested on RHEL 6.6, rebuilt sssd-1.11.6-30.el6_6.4). With this patch sssd_sudo no longer queries LDAP for sudo rules of filter_users users.
the problem is that with current master and 1.12 the domain local groups
from subdomain are not filtered.
The 1st patch partially fixes the problem. The name of group is not visible
after "id user", but there is a GID which does not have a name.
BTW without this patch "Distributions groups" needn't be filtered with disabled
tokengroups. It might explain some cases where groups were missing with
disabled tokengroups. Users might use this bug as a workaround.
The last patch filter domain local groups from subdomains
while doing initgroups. So there will not be GIDs without name.
Please try to review patches very soon. So we can fix regression with
domain local groups caused by recent optimalisation of initgroups.
the attached simple patches add more debugging to nsupdate runs and
capture nsupdate stderr to the sssd debug logs. I used them to get more
data in case where nsupdate was failing without more data.
I would like to propose disabling the cleanup task by default. It causes
problems and is not really useful in my opinion.
The cleanup task was designed to keep the cache size within certain
limits. This is how it roughly works now:
- find users who have never logged in by default. If
account_cache_expiration is set, find users who loggged in later
- delete the matching set of users
- find groups that have no members
- delete the matching set of groups
So unless account_cache_expiration is set to something sensible, only
empty groups are removed and that's quite a corner case. The above
effectivelly walks the whole database, especially the groups step is
quite slow with a huge database. The whole cleanup task also runs in a
single sysdb transaction, which means all other transactions are blocked
while the cleanup task crunches the database. Just today I've seen two
users/customers for which disabling the cleanup helped performance.
The alternative would be to fix the cleanup task. So far I only checked
that indexed attributes are used -- they are. But I don't see much value
in the cleanup task to be honest. If an entry is explicitly requested,
then the back end removes the cached entry when evaluating the negative
Therefore, I think we should disable the cleanup task completely unless
account_cache_expiration is set to a non-default value. If
account_cache_expiration was set, then the cleanup task would run as it
does now. Opinions?