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/sssd-users@lists.fedorahoste...