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)
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org