issue with ldap_access_filter

[Kamil Kosowski]

Hello 
I am doing some reverse engineering in my current company : 

I have a server which is acting as a gateway for other services, it's like entry point
exposed to the world. People are connecting to this server on port 443 via for example
DBeaver. 
The same server can be accessed by a group of admin via ssh - ssh should be only for
admins, admins are placed in the different domain while all other users are in domain.net

for clarification group, "NoOne" doesn't exist in AD 

what is happening : 
- if someone is trying to access this node via ssh, I see in the SSSD logs that, after
validating user, SSSD is performing access check filter and that is ok
- if someone is trying to access this node via DBeaver on port 443, SSSD never triggers
access check filter after user validation and the user gets access 


if there is any way to exclude performing access_filter for every connection except ssh? I
cannot find this configuration and apparently, this is how it works right now, while I am
deploying new Gateway server with the same configuration and on the new server no matter
what I do, access_filter check is always triggered 


config:

[domain/admins.net]
allow ssh config

[domain/domain.net]
debug_level = 9
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_uri = ldaps://node.net:636
ldap_user_search_base =
DC=domain,DC=NET?subtree?(|(memberOf=CN=DSP,OU=Security,OU=Groups,OU=Town,OU=PL,OU=COMP,OU=Users
& Workstations,DC=domain,DC=NET)(memberOf=CN=IMD,OU=Security,OU=IMD,OU=Global,OU=Users
& Workstations,DC=domain,DC=NET))
ldap_schema = ad
ldap_id_mapping = True
ldap_default_bind_dn = CN=USERMASTER,OU=Service
Accounts,OU=Global,OU=Servers,DC=domain,DC=NET
ldap_default_authtok = ################
ldap_user_name = sAMAccountName
ldap_user_member_of = memberOf
ldap_user_gid_number = primaryGroupID
ldap_user_shell = /bin/bash
override_homedir = /home/%u
ldap_group_name = sAMAccountName
ldap_group_search_base = DC=domain,DC=NET?subtree?(|(cn=Data*)(cn=Users))
ldap_use_tokengroups = false
ldap_group_member = member
ldap_group_object_class = group
ldap_sudorule_object_class = person
ldap_sudorule_name = sAMAccountName
cache_credentials = True
use_fully_qualified_names = False
ldap_tls_cacert = /etc/sssd/ROOT_AD_RO.pem
ldap_access_order = filter
ldap_access_filter = (|(memberOf=NoOne,DC=domain,DC=NET)

[Sumit Bose]

On Thu, Aug 22, 2019 at 09:21:56AM -0000, Kamil Kosowski wrote:
>  Hello 
>  I am doing some reverse engineering in my current company : 
>  
>  I have a server which is acting as a gateway for other services, it's like entry
> point exposed to the world. People are connecting to this server on port 443 via for
> example DBeaver. 
>  The same server can be accessed by a group of admin via ssh - ssh should be only for
> admins, admins are placed in the different domain while all other users are in domain.net
>  
>  for clarification group, "NoOne" doesn't exist in AD 
>  
>  what is happening : 
>  - if someone is trying to access this node via ssh, I see in the SSSD logs that, after
> validating user, SSSD is performing access check filter and that is ok
>  - if someone is trying to access this node via DBeaver on port 443, SSSD never triggers
> access check filter after user validation and the user gets access 
>  
>  
>  if there is any way to exclude performing access_filter for every connection except ssh?
> I cannot find this configuration and apparently, this is how it works right now, while I
> am deploying new Gateway server with the same configuration and on the new server no
> matter what I do, access_filter check is always triggered  
Hi,

from the systems perspective authentication and access control are
handled by PAM. For each service you should find a PAM configuration
file in /etc/pam.d/SERVICE_NAME, e.g. /etc/pam.d/sshd. In these files
(or files included by them) the lines starting with 'account' are
responsible for the access control. You can remove the account line which
contain 'pam_sss.so' from the PAM service files where you do not want
SSSD to do access control to avoid the check.

If you prefer a more central management please check the
ldap_user_authorized_service option in man sssd-ldap. Or is you like to
use SSSD's AD provider you can use GPO's on AD to control the access,
please see the ad_gpo_* options in man sssd-ad for details.

HTH

bye,
Sumit

> 
> 
> config:
> 
> [domain/admins.net]
> allow ssh config
> 
> [domain/domain.net]
> debug_level = 9
> id_provider = ldap
> auth_provider = ldap
> access_provider = ldap
> ldap_uri = ldaps://node.net:636
> ldap_user_search_base =
DC=domain,DC=NET?subtree?(|(memberOf=CN=DSP,OU=Security,OU=Groups,OU=Town,OU=PL,OU=COMP,OU=Users
& Workstations,DC=domain,DC=NET)(memberOf=CN=IMD,OU=Security,OU=IMD,OU=Global,OU=Users
& Workstations,DC=domain,DC=NET))
> ldap_schema = ad
> ldap_id_mapping = True
> ldap_default_bind_dn = CN=USERMASTER,OU=Service
Accounts,OU=Global,OU=Servers,DC=domain,DC=NET
> ldap_default_authtok = ################
> ldap_user_name = sAMAccountName
> ldap_user_member_of = memberOf
> ldap_user_gid_number = primaryGroupID
> ldap_user_shell = /bin/bash
> override_homedir = /home/%u
> ldap_group_name = sAMAccountName
> ldap_group_search_base = DC=domain,DC=NET?subtree?(|(cn=Data*)(cn=Users))
> ldap_use_tokengroups = false
> ldap_group_member = member
> ldap_group_object_class = group
> ldap_sudorule_object_class = person
> ldap_sudorule_name = sAMAccountName
> cache_credentials = True
> use_fully_qualified_names = False
> ldap_tls_cacert = /etc/sssd/ROOT_AD_RO.pem
> ldap_access_order = filter
> ldap_access_filter = (|(memberOf=NoOne,DC=domain,DC=NET)
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/[e-mail]...