2:56 a.m.
Hi,
I am running sssd-1.16.4-21.el7.x86_64 (from CR repo) on a CentOS 7 client. I authenticate
to AD 2016, and control access to servers using GPO. For some reason, a completely
unprivileged user in AD is allowed to login, and I'd like to understand why.
Here's a sanitized sssd.conf:
[sssd]
domains = prd.domain.com
config_file_version = 2
services = nss, pam, sudo
full_name_format = %1$s
default_domain_suffix = prd.domain.com
[domain/prd.domain.com]
debug_level = 9
ad_domain = prd.domain.com
ad_site = XX1
ad_server = dc000.prd.domain.com, dc001.prd.domain.com
krb5_realm = PRD.DOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = true
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = ad
ldap_sudo_search_base = DC=domain,DC=com
entry_cache_sudo_timeout = 10
enumerate = true
dyndns_update = false
ad_gpo_access_control = enforcing
ldap_idmap_default_domain_sid = S-1-5-21-6607581186-1994368826-2594857426
ldap_idmap_default_domain = prd.domain.com
ad_gpo_implicit_deny = true
auto_private_groups = true
ad_gpo_ignore_unreadable = true
When I try to SSH to the client using my unprivileged user, I am getting the following
output from the SSSD debug:
[sysdb_gpo_get_gpo_result_setting] (0x0400): key [SeDenyRemoteInteractiveLogonRight] value
[*S-1-5-32-546]
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 1
[ad_gpo_access_check] (0x0400): denied_sids[0] = S-1-5-32-546
... snip ...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid =
S-1-5-21-6607581186-1994368826-2594857426-2570
[ad_gpo_access_check] (0x0400): group_sids[0] =
S-1-5-21-6607581186-1994368826-2594857426-513
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
I'm trying to understand why this user is being granted access. I find it especially
confusing as there is clearly one deny sid and no allow sids detected. The wanted
behaviour is that the user should be denied access as long as I've not explicitly
allowed it in AD.
Thanks!
3:56 a.m.
Even when I reconfigure AD to make sure there is no applicable GPO's found, I'm
still granted access with my unprivileged user.
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 0
...snip...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-1107582786-xxx-2594897426-2570
[ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-1107582786-xxx-2594897426-513
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
In this case, shouldn't the new feature "ad_gpo_implicit_deny" kick in and
make sure the user is denied?
10:29 a.m.
New subject: AD user is granted access when it should be denied
On 9/11/19 10:56 AM, Emil Petersson wrote:
Even when I reconfigure AD to make sure there is no applicable
GPO's found, I'm still granted access with my unprivileged user.
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 0
...snip...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid =
S-1-5-21-1107582786-xxx-2594897426-2570
[ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-1107582786-xxx-2594897426-513
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
In this case, shouldn't the new feature "ad_gpo_implicit_deny" kick in and
make sure the user is denied?
Hi,
you are correct.
It should deny access to the user. Both this log and the log
from your previous email look like there is some issue with SSSD. I will
try to reproduce it locally, but from the logs you provided it looks
like a bug.
Michal
3:28 a.m.
New subject: AD user is granted access when it should be denied
Hi,
The docs for ad_gpo_implicit_deny reads:
"Normally when no applicable GPOs are found the users are allowed access. When this
option is set to True users will be allowed access only when explicitly allowed by a GPO
rule. Otherwise users will be denied access. This can be used to harden security but be
careful when using this option because it can deny access even to users in the built-in
Administrators group if no GPO rules apply to them."
In my case, there are GPOs found, it's just that none of them touches
RemoteInteractiveLogonRight or DenyRemoteInteractiveLogonRight.
Does ad_gpo_implicit_deny work in such a way that it's only effective when no (0) GPOs
are found? That might explain the behaviour I'm seeing. If this is the case, I suggest
that ad_gpo_implicit_deny should be effective also when none of the detected GPOs
explicitly allows or denies remote logon.
4 a.m.
New subject: AD user is granted access when it should be denied
On 10/3/19 10:28 AM, Emil Petersson wrote:
Hi,
The docs for ad_gpo_implicit_deny reads:
"Normally when no applicable GPOs are found the users are allowed access. When this
option is set to True users will be allowed access only when explicitly allowed by a GPO
rule. Otherwise users will be denied access. This can be used to harden security but be
careful when using this option because it can deny access even to users in the built-in
Administrators group if no GPO rules apply to them."
In my case, there are GPOs found, it's just that none of them touches
RemoteInteractiveLogonRight or DenyRemoteInteractiveLogonRight.
Does ad_gpo_implicit_deny work in such a way that it's only effective when no (0)
GPOs are found? That might explain the behaviour I'm seeing. If this is the case, I
suggest that ad_gpo_implicit_deny should be effective also when none of the detected GPOs
explicitly allows or denies remote logon.
Sorry, I missed your response.
You are right the ad_gpo_implicit_deny only works when there is not
policy found on the server that applies to the user (0 GPOs applicable).
If there is a GPO that is applicable, but does not contain any
access control rules then the ad_gpo_implicit_deny does not kick in.
I completely missread the logs you send before. I gave the feature
a smoke test and it worked for me.
Michal
4:43 a.m.
New subject: AD user is granted access when it should be denied
Ok, thanks, that explains it.
All I want is a way to make sure that a user, which I have not explicitly allowed access,
is denied. In other words... default behaviour for all logins should always be DENY,
regardless of number of GPOs found. Obviously, a GPO that does contain access control
rules should override this default behavior.
Right now we are forced to fall back to either "access_provider=simple" or
"ad_access_filter" just to make sure that the default behavior for logins are
DENY, which unfortunately defeats the whole idea of using GPO for access control.
Any advice on how to achieve my desired functionality is appreciated.
Thanks!
8:37 a.m.
New subject: AD user is granted access when it should be denied
On 10/10/19 11:43 AM, Emil Petersson wrote:
Ok, thanks, that explains it.
All I want is a way to make sure that a user, which I have not explicitly allowed access,
is denied. In other words... default behaviour for all logins should always be DENY,
regardless of number of GPOs found. Obviously, a GPO that does contain access control
rules should override this default behavior.
Right now we are forced to fall back to either "access_provider=simple" or
"ad_access_filter" just to make sure that the default behavior for logins are
DENY, which unfortunately defeats the whole idea of using GPO for access control.
Any advice on how to achieve my desired functionality is appreciated.
Thanks!
Currently your only way is to actually define the GPO
on the AD server. I would probably put it to a separate GPO,
something like access_control_gpo and define these rules there:
Allow log on locally
Allow log on through remote desktop sevices
Allow log on as a service
Allow log on as a batch job
Access this computer from the network
Define these rules and put Administrators group to all of them.
Then you can add whatever user/group you want to login (you are probably
mostly interested in the Allow log on locally and Allow log on through
remote desktop services if you are using default PAM to GPO rule
mapping, but it is still better to define all these rules explicitly if
you really want a complete whitelist on the server).
Or alternatively make all GPOs on the server not applicable
to the SSSD host (but I agree that this is kind of clumsy
solution if you have many GPOs, so it is better to go
with the above and define the policies).
Regarding SSSD side options.
Maybe we should add a stronger mode for ad_gpo_implicit_deny to
"only allow explicitly allowed" users/groups not only
deny access if there are no applicable GPOs. I think such
option would be good hardening option, but it would basically
ignore all Deny rules on the server (OTOH if someone wants to
allow only whitelisted users/groups they would not use deny
rules, so that is actually not a problem). Will you file
an RFE or should I? Feel free to copy paste this discussion
to the ticket.
Michal
4:31 p.m.
Regarding SSSD side options.
Maybe we should add a stronger mode for ad_gpo_implicit_deny to
"only allow explicitly allowed" users/groups not only
deny access if there are no applicable GPOs. I think such
option would be good hardening option, but it would basically
ignore all Deny rules on the server (OTOH if someone wants to
allow only whitelisted users/groups they would not use deny
rules, so that is actually not a problem). Will you file
an RFE or should I? Feel free to copy paste this discussion
to the ticket.
I've created what I hope counts as an RFE at https://pagure.io/SSSD/sssd/issue/4097,
with our conversation included. Thanks!
1667
days inactive
1697
days old
sssd-users@lists.fedorahosted.org
7 comments
2 participants
participants (2)
-
Emil Petersson -
Michal Židek