sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim
We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf.
...
[libdefaults]
...
default_ccache_name = DIR:/tmp/krb5cc_%{uid}
...
user@server:~$ klist
Ticket cache: DIR::/tmp/krb5cc_888/tkt
Default principal: user@REALM
Valid starting Expires Service principal
09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM
Each ticket is stored in a separate file.
For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails.
In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour :
krb5_ccachedir (string)
Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
krb5_ccname_template (string)
Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted:
[...]
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
...
I have tried to both set and unset, the two parameters in question like this:
krb5_ccachedir = /tmp/krb5cc_%U
krb5_ccname_template = DIR: %d
krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX
But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login.
If I set the +x bit on the directory manually as the root-user, everything works.
2 months, 2 weeks
sssd with samba
by Edouard Guigné
Dear sssd users,
I would like to get informations about the use of sssd with samba
(centos 7, samba 4.8.3).
I need it because I configured a samba share, accessible with sssd.
The authentication is against a windows AD.
My /etc/nsswitch.cnf is configured only with sssd :
/passwd: files sss//
//shadow: files sss//
//group: files sss/
For an other purpose, I set an sftpd access also configured with sssd
against the AD.
I followed some discussions on the samba user list about samba + sssd.
I would like to understand if there are some issues with sssd and samba
4.8.3 on centos 7 ?
Or is it with next RHEL 8 ?
/The RHEL 8 documentation states this: //
////
//"Red Hat only supports running Samba as a server with the winbindd //
//service to provide domain users and groups to the local system. Due to //
//certain limitations, such as missing Windows access control list (ACL) //
//support and NT LAN Manager (NTLM) fallback, SSSD is not supported." //
////
//https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers////
////
//What's confusing is that the RHEL 7 documentation says: //
////
//"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this //
//functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer //
//need to run Winbind and SSSD in parallel to access SMB shares. For //
//example, accessing the Access Control Lists (ACLs) no longer requires //
//Winbind on SSSD clients." //
////
//and //
////
//"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares //
//For most SSSD clients, using SSSD is recommended:" //
////
//and most worrisome, in my use case: //
////
//"In environments with direct Active Directory integration where the //
//clients use SSSD for general Active Directory user mappings, using //
//Winbind for the SMB ID mapping instead of SSSD can result in //
//inconsistent mapping."
/
In my case, running samba 4.8.3 with SSSD on centos 7 do I need to :
- enable and start winbind service , in conjunction to sssd ?
- or only sssd is enough with samba ?
- Do I have to fear issues in next release of sssd for the support of
samba ? especially for acls support ?/
/
A nsswitch.conf like :
passwd: files sss winbind
shadow: files sss winbind
group: files sss winbind
or
passwd: files winbind sss
shadow: files winbind sss
group: files winbind sss
Does not seem to work... I test and this is not stable.
Best Regards,
Edouard
3 months, 1 week
Re: SSH user fails system error 4
by Striker Leggette
Debugging itself adds very little processing usage overhead with SSSD.
Depending on how many connections you are receiving in any given time
will ultimately determine how large the debugging grows on the system.
Logging does not cause a large amount of space consumption. I would
advise adding 'debug_level = 9' to all sections of sssd.conf, restart
SSSD and simply keep an eye on the storage usage to make sure it doesn't
use up all space until the issue can be reproduced.
On 6/22/20 11:06 AM, Sangster, Mark wrote:
> Hello,
>
> My difficult lies with being able to debug this. The need to leave the debug on for ~3-4 days on a production system, is something that I would not be comfortable doing.
>
> We are using Active Directory, Domain/Functional forest level Windows Server 2012 R2.
>
> We are in the midst of switching us stuff to be the AD provider but this is still KRB5/LDAP.
>
> [sssd]
> config_file_version = 2
> domains = DOMAIN
> services = nss, pam
> [domain/DOMAIN]
> ldap_referrals = false
> cache_credentials = true
> enumerate = false
> id_provider = ldap
> auth_provider = krb5
> ldap_uri = ldap://LDAP1.DOMAIN, ldap://LDAP2.DOMAIN
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = SERVER$@DOMAIN
> ldap_schema = rfc2307bis
> ldap_user_search_base = DC=DOMAIN,DC=BASE
> ldap_user_object_class = user
> ldap_group_search_base = DC=DOMAIN,DC=BASE
> ldap_group_object_class = group
> ldap_account_expire_policy = ad
> ldap_force_upper_case_realm = true
> krb5_server = LDAP1.DOMAIN, LDAP2.DOMAIN
> krb5_realm = DOMAIN
> krb5_canonicalize = false
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_name = sAMAccountName
> ldap_user_principal = None
> access_provider = simple
> simple_allow_groups = USERS_GROUP
>
> I re-joined the machine to the domain to ensure that wasn't the source of issues.
>
> If there is an appropriate debug level which wouldn't be negative to a production system, I can try that out.
>
> Cheers
> Mark
>
>
> -----Original Message-----
> From: Lukas Slebodnik <lslebodn(a)redhat.com>
> Sent: 18 June 2020 12:04
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: SSH user fails system error 4
>
> CAUTION: External email. Ensure this message is from a trusted source before clicking links/attachments.
>
>
> On (18/06/20 09:11), Sangster, Mark wrote:
>> Hello,
>>
>> We are experiencing an issue with a user when they attempt to login. Other users can continue to login. It does seem to repeat on this specific user.
>>
>> If I blitz the SSSD cache and restart it, then they find they can login again.
>>
>> They indicated that just prior to the event, they were forced to reboot their machine (i.e. unclean disconnect) and it was after that they couldn’t login.
>>
>> This was the successful session just before:
>>
>> Jun 17 08:00:58 server sshd[11882]: pam_sss(sshd:auth): authentication
>> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP>
>> user=username Jun 17 08:00:58 server sshd[11882]: Accepted password for
>> username from <CLIENTIP> port 59680 ssh2 Jun 17 08:00:59 server
>> sshd[11882]: pam_unix(sshd:session): session opened for user username
>> by (uid=0) Jun 17 13:22:17 server sshd[11882]: pam_unix(sshd:session):
>> session closed for user username
>>
>> The next session which failed:
>>
>> Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:auth): authentication
>> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP>
>> user=username Jun 17 13:33:13 server sshd[13210]:
>> pam_sss(sshd:account): Access denied for user username: 4 (System
>> error) Jun 17 13:33:13 server sshd[13210]: Failed password for username
> >from <CLIENTIP> port 50114 ssh2 Jun 17 13:33:13 server sshd[13210]:
>> fatal: Access denied for user username by PAM account configuration
>> [preauth]
>>
>> There does not look to be any additional log information in SSSD representing the error. The troubleshooting suggested I follow up here for “system error 4”.
>>
>> It would be tricky to run debug on this, as this took 4 days until the failure reappeared and we might fill our log space very quickly.
>>
> Pam return code 4 (System error) means some unexpected situation in sssd (usually in backend)
>
> I would recomment to follow following guide https://sssd.io/docs/users/troubleshooting.html
>
> It would be good to also provide more details about your configuration type/version of directory server, ...
>
> LS
> _______________________________________________
> 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...
>
>
> The University of Aberdeen is a charity registered in Scotland, No SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.
> _______________________________________________
> 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...
8 months
Stability/intended purpose of ccacheFile user attribute
by Sam Morris
/etc/auto.smb is a script used by autofs to make Windows file servers accessible to the automounter. The script basically works by by parsing the output of 'smbclient -L SERVER'. My workplace has a fairly vanilla FreeIPA setup with a one-way trust to an Active Directory domain, and in order for smbclient to be able to list a file server's shares, it has to be able to access the Kerberos ticket cache of the user who requested the mount in order to authenticate to the file servers.
This isn't easy, because the script is launched by autofs, so it doesn't really know anything about the user other than its UID and name. The standard script just checks in some standard hardcoded locations: DIR:/run/user/$AUTOFS_UID/krb5_cc_* and /tmp/krb5cc_$AUTOFS_UID; there's no support for other locations, or any of the more interesting credential cache types.
I discovered that SSSD has a 'ccacheFile' attribute that points to the location of the user's Kerberos ticket cache. After adding '+ccacheFile' to [ifp]user_attributes in sssd.conf and restarting sssd, the following patch to /etc/auto.smb got things working.
The patch is pretty straightforward, it just retrieves the ccacheFile attribute via the sssd infopipe API:
--- /usr/share/autofs/conffiles/auto.smb 2020-01-15 22:04:23.000000000 +0000
+++ /etc/auto.smb 2020-06-28 19:07:01.941702373 +0100
@@ -24,7 +24,19 @@
get_krb5_cache() {
cache=
- uid=${UID}
+ uid=${AUTOFS_UID}
+ # This requires busctl, jq, sssd's infopipe responder, and for sssd.conf to contain [ifp]user_attributes = +ccacheFile
+ # ... maybe we should just su to the user to run smbclient?
+ if [[ -x /usr/bin/busctl ]] && [[ -x /usr/bin/jq ]]; then
+ _user_obj=$(busctl -j call org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users FindByID u "$uid" | jq -r '.data[0]')
+ if [[ -n $_user_obj ]]; then
+ cache=$(busctl -j get-property org.freedesktop.sssd.infopipe "$_user_obj" org.freedesktop.sssd.infopipe.Users.User extraAttributes | jq -r '.data.ccacheFile[0]')
+ if [[ -n $cache ]]; then
+ return
+ fi
+ fi
+ fi
for x in $(ls -d /run/user/$uid/krb5cc_* 2>/dev/null); do
if [ -d "$x" ] && klist -s DIR:"$x"; then
cache=DIR:$x
So, I come to this list to find out whether this is a good idea or not: is this attribute an implementation detail, or something that a client of sssd can rely upon? If not, would you consider making it stable, or provide another mechanism to retrieve a user's Kerberos credential cache location--or else propose another mechanism (e.g., I suppose the script _could_ use runuser, su or sudo, etc., to run smbclient as the requesting user, which would automatically pick up KRB5CCNAME via pam_sssd.so)... would that be a better way to do this?
(It appears that the cifs code within the kernel itself has a similar problem; it is able to find a user's Kerberos credentials by use of cifs.upcall(8), which peeks into the environment of the process that caused a key to be requested, and uses the value of KRB5CCNAME that it finds there. autofs can't do something similar because the kernels doesn't make the PID of the requesting process available to it.)
BTW, I might have run into a bug while figuring out the above. I noticed that changes to [libdefaults]default_ccache_name in krb5.conf weren't taking effect even after a reboot! It turns out that pam_sss.so sets KRB5CCNAME during login to the value from its cache, rather than from krb5.conf. I ended up using ldbedit to remove the ccacheFile attribute from my user record and logging in again, whereupon the attribute was added again with the new expected value.
--
Sam Morris <https://robots.org.uk>
8 months, 1 week
Re: SSH user fails system error 4
by Lukas Slebodnik
On (18/06/20 09:11), Sangster, Mark wrote:
>Hello,
>
>We are experiencing an issue with a user when they attempt to login. Other users can continue to login. It does seem to repeat on this specific user.
>
>If I blitz the SSSD cache and restart it, then they find they can login again.
>
>They indicated that just prior to the event, they were forced to reboot their machine (i.e. unclean disconnect) and it was after that they couldn’t login.
>
>This was the successful session just before:
>
>Jun 17 08:00:58 server sshd[11882]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP> user=username
>Jun 17 08:00:58 server sshd[11882]: Accepted password for username from <CLIENTIP> port 59680 ssh2
>Jun 17 08:00:59 server sshd[11882]: pam_unix(sshd:session): session opened for user username by (uid=0)
>Jun 17 13:22:17 server sshd[11882]: pam_unix(sshd:session): session closed for user username
>
>The next session which failed:
>
>Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP> user=username
>Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:account): Access denied for user username: 4 (System error)
>Jun 17 13:33:13 server sshd[13210]: Failed password for username from <CLIENTIP> port 50114 ssh2
>Jun 17 13:33:13 server sshd[13210]: fatal: Access denied for user username by PAM account configuration [preauth]
>
>There does not look to be any additional log information in SSSD representing the error. The troubleshooting suggested I follow up here for “system error 4”.
>
>It would be tricky to run debug on this, as this took 4 days until the failure reappeared and we might fill our log space very quickly.
>
Pam return code 4 (System error) means some unexpected situation in sssd
(usually in backend)
I would recomment to follow following guide
https://sssd.io/docs/users/troubleshooting.html
It would be good to also provide more details about your configuration
type/version of directory server, ...
LS
8 months, 1 week
SSH user fails system error 4
by Sangster, Mark
Hello,
We are experiencing an issue with a user when they attempt to login. Other users can continue to login. It does seem to repeat on this specific user.
If I blitz the SSSD cache and restart it, then they find they can login again.
They indicated that just prior to the event, they were forced to reboot their machine (i.e. unclean disconnect) and it was after that they couldn’t login.
This was the successful session just before:
Jun 17 08:00:58 server sshd[11882]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP> user=username
Jun 17 08:00:58 server sshd[11882]: Accepted password for username from <CLIENTIP> port 59680 ssh2
Jun 17 08:00:59 server sshd[11882]: pam_unix(sshd:session): session opened for user username by (uid=0)
Jun 17 13:22:17 server sshd[11882]: pam_unix(sshd:session): session closed for user username
The next session which failed:
Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP> user=username
Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:account): Access denied for user username: 4 (System error)
Jun 17 13:33:13 server sshd[13210]: Failed password for username from <CLIENTIP> port 50114 ssh2
Jun 17 13:33:13 server sshd[13210]: fatal: Access denied for user username by PAM account configuration [preauth]
There does not look to be any additional log information in SSSD representing the error. The troubleshooting suggested I follow up here for “system error 4”.
It would be tricky to run debug on this, as this took 4 days until the failure reappeared and we might fill our log space very quickly.
Thanks
Mark
------------------------------------------------------------------------
Mark Sangster
Server Infrastructure Specialist
Information Technology Services | University of Aberdeen
t: +44 (0)1224 27-3315 | e: mark(a)abdn.ac.uk<mailto:mark@abdn.ac.uk> | u: http://www.abdn.ac.uk/it/
The University of Aberdeen is a charity registered in Scotland, No SC013683.
Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.
8 months, 2 weeks
Re: Access Filters
by Sumit Bose
On Thu, Jun 11, 2020 at 07:29:12AM +0000, Sangster, Mark wrote:
> I wish the control to be external to the system. It allows us to group people by dept/courses/etc and add them to systems when desired, rather than having to change SSSD periodically. So management within AD is preferable.
Hi,
you might want to have a look at GPO based access control as well, see
descriptions of the ad_gpo_* options in man sssd_ad for details.
bye,
Sumit
>
> I did sort of figure that PAM was going to be the local user control but wasn't sure if SSSD could handle that as well. Thanks!
>
> Also, thank you Personne that looks like what I need to do.
>
> -----Original Message-----
> From: patrick.hush(a)comcast.net <patrick.hush(a)comcast.net>
> Sent: 10 June 2020 16:24
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>; Sangster, Mark <m.v.sangster(a)abdn.ac.uk>
> Subject: Re: [SSSD-users] Access Filters
>
> CAUTION: External email. Ensure this message is from a trusted source before clicking links/attachments.
>
>
> Rather than filtering off a single group, why not use the simple_allow_groups key value? This will allow mulitiple groups to access the system should the need ever arise.
> For the local users, that is outside sssd for the most part, look at your pam configs and nsswitch.
>
>
>
>
> > On June 10, 2020 at 5:42 AM "Sangster, Mark" <m.v.sangster(a)abdn.ac.uk> wrote:
> >
> >
> > Hello,
> >
> > I was attempting to utilise the AD provider for access control, however I cannot make it work with members of nested groups. i.e. when using the LDAP_MATCHING_RULE_IN_CHAIN.
> >
> > This functions:
> >
> > access_provider = ldap
> > ldap_sasl_authid = SERVER$@DOMAIN
> > ldap_access_filter =
> > (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
> >
> > This doesn’t:
> >
> > access_provider = ad
> > ad_access_filter =
> > (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
> >
> > Have I missed anything?
> >
> > It would also be useful if it is possible to allow local users access alongside the remote users. e.g. allow both “domain_account” and “local_account” access. Is that possible?
> >
> > Thanks
> > Mark
> >
> > ----------------------------------------------------------------------
> > --
> > Mark Sangster
> > Server Infrastructure Specialist
> >
> > Information Technology Services | University of Aberdeen
> > t: +44 (0)1224 27-3315 | e: mailto:mark@abdn.ac.uk | u:
> > http://www.abdn.ac.uk/it/
> >
> >
> > The University of Aberdeen is a charity registered in Scotland, No SC013683.
> > Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.
> > _______________________________________________
> > 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.fedoraho
> > sted.org
>
>
> The University of Aberdeen is a charity registered in Scotland, No SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.
> _______________________________________________
> 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...
8 months, 2 weeks
Re: Access Filters
by Personne
What you are trying to do, looks like RBAC.
You have 2 main options to deal with your need
1) Allow server access using the sssd.conf file and using ad_access_filter,
using this option, you can use an AD group called: allowed_to_access_this
server
Then in AD you just have to make your users member of this group.
If they are not member they will be prompted for their credentials, but
refused access
2) it is a mixed of sshd_config and sudoers, where you can also use AD
group as long as they have GID of course
user Allow_Groups in sshd_config, if you do not everyone will have access
use sudoers to limit their permissions
Good luck
On Thu, Jun 11, 2020 at 8:27 AM Sangster, Mark <m.v.sangster(a)abdn.ac.uk>
wrote:
> I wish the control to be external to the system. It allows us to group
> people by dept/courses/etc and add them to systems when desired, rather
> than having to change SSSD periodically. So management within AD is
> preferable.
>
> I did sort of figure that PAM was going to be the local user control but
> wasn't sure if SSSD could handle that as well. Thanks!
>
> Also, thank you Personne that looks like what I need to do.
>
> -----Original Message-----
> From: patrick.hush(a)comcast.net <patrick.hush(a)comcast.net>
> Sent: 10 June 2020 16:24
> To: End-user discussions about the System Security Services Daemon <
> sssd-users(a)lists.fedorahosted.org>; Sangster, Mark <
> m.v.sangster(a)abdn.ac.uk>
> Subject: Re: [SSSD-users] Access Filters
>
> CAUTION: External email. Ensure this message is from a trusted source
> before clicking links/attachments.
>
>
> Rather than filtering off a single group, why not use the
> simple_allow_groups key value? This will allow mulitiple groups to access
> the system should the need ever arise.
> For the local users, that is outside sssd for the most part, look at your
> pam configs and nsswitch.
>
>
>
>
> > On June 10, 2020 at 5:42 AM "Sangster, Mark" <m.v.sangster(a)abdn.ac.uk>
> wrote:
> >
> >
> > Hello,
> >
> > I was attempting to utilise the AD provider for access control, however
> I cannot make it work with members of nested groups. i.e. when using the
> LDAP_MATCHING_RULE_IN_CHAIN.
> >
> > This functions:
> >
> > access_provider = ldap
> > ldap_sasl_authid = SERVER$@DOMAIN
> > ldap_access_filter =
> > (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
> >
> > This doesn’t:
> >
> > access_provider = ad
> > ad_access_filter =
> > (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
> >
> > Have I missed anything?
> >
> > It would also be useful if it is possible to allow local users access
> alongside the remote users. e.g. allow both “domain_account” and
> “local_account” access. Is that possible?
> >
> > Thanks
> > Mark
> >
> > ----------------------------------------------------------------------
> > --
> > Mark Sangster
> > Server Infrastructure Specialist
> >
> > Information Technology Services | University of Aberdeen
> > t: +44 (0)1224 27-3315 | e: mailto:mark@abdn.ac.uk | u:
> > http://www.abdn.ac.uk/it/
> >
> >
> > The University of Aberdeen is a charity registered in Scotland, No
> SC013683.
> > Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir.
> SC013683.
> > _______________________________________________
> > 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.fedoraho
> > sted.org
>
>
> The University of Aberdeen is a charity registered in Scotland, No
> SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir.
> SC013683.
> _______________________________________________
> 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...
>
8 months, 3 weeks
Re: Access Filters
by patrick.hush@comcast.net
Rather than filtering off a single group, why not use the simple_allow_groups key value? This will allow mulitiple groups to access the system should the need ever arise.
For the local users, that is outside sssd for the most part, look at your pam configs and nsswitch.
> On June 10, 2020 at 5:42 AM "Sangster, Mark" <m.v.sangster(a)abdn.ac.uk> wrote:
>
>
> Hello,
>
> I was attempting to utilise the AD provider for access control, however I cannot make it work with members of nested groups. i.e. when using the LDAP_MATCHING_RULE_IN_CHAIN.
>
> This functions:
>
> access_provider = ldap
> ldap_sasl_authid = SERVER$@DOMAIN
> ldap_access_filter = (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
>
> This doesn’t:
>
> access_provider = ad
> ad_access_filter = (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
>
> Have I missed anything?
>
> It would also be useful if it is possible to allow local users access alongside the remote users. e.g. allow both “domain_account” and “local_account” access. Is that possible?
>
> Thanks
> Mark
>
> ------------------------------------------------------------------------
> Mark Sangster
> Server Infrastructure Specialist
>
> Information Technology Services | University of Aberdeen
> t: +44 (0)1224 27-3315 | e: mailto:mark@abdn.ac.uk | u: http://www.abdn.ac.uk/it/
>
>
> The University of Aberdeen is a charity registered in Scotland, No SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.
> _______________________________________________
> 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...
8 months, 3 weeks
Re: Access Filters
by Personne
#Permit access with recursive group
ad_access_filter = DOM:glop.com:(memberOf:1.2.840.113556.1.4.1941:=cn=
rights-srv-realm-allowed,CN=Users,DC=glop,DC=com)
I never encountered any issue with local users and AD users.
On Wed, Jun 10, 2020, 7:57 AM Sangster, Mark <m.v.sangster(a)abdn.ac.uk>
wrote:
> Many thanks, I will hunt for that.
>
>
>
> Any advice on the local/remote user controls?
>
>
>
> *From:* Personne <cpdivers(a)gmail.com>
> *Sent:* 10 June 2020 15:47
> *To:* End-user discussions about the System Security Services Daemon <
> sssd-users(a)lists.fedorahosted.org>
> *Subject:* [SSSD-users] Re: Access Filters
>
>
>
> CAUTION: External email. Ensure this message is from a trusted source
> before clicking links/attachments.
>
>
>
> I had the exact same problem a week or 2 ago, look at the documentation or
> my previous emails you will have the answer.
>
>
>
> On Wed, Jun 10, 2020, 5:43 AM Sangster, Mark <m.v.sangster(a)abdn.ac.uk>
> wrote:
>
> Hello,
>
> I was attempting to utilise the AD provider for access control, however I
> cannot make it work with members of nested groups. i.e. when using the
> LDAP_MATCHING_RULE_IN_CHAIN.
>
> This functions:
>
> access_provider = ldap
> ldap_sasl_authid = SERVER$@DOMAIN
> ldap_access_filter =
> (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
>
> This doesn’t:
>
> access_provider = ad
> ad_access_filter =
> (memberOf:1.2.840.113556.1.4.1941:=CN=ServerGroup,OU=Groups,DC=DOMAIN)
>
> Have I missed anything?
>
> It would also be useful if it is possible to allow local users access
> alongside the remote users. e.g. allow both “domain_account” and
> “local_account” access. Is that possible?
>
> Thanks
> Mark
>
> ------------------------------------------------------------------------
> Mark Sangster
> Server Infrastructure Specialist
>
> Information Technology Services | University of Aberdeen
> t: +44 (0)1224 27-3315 | e: mailto:mark@abdn.ac.uk | u:
> http://www.abdn.ac.uk/it/
>
>
> The University of Aberdeen is a charity registered in Scotland, No
> SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir.
> SC013683.
> _______________________________________________
> 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...
>
>
>
> The University of Aberdeen is a charity registered in Scotland, No
> SC013683.
> Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir.
> SC013683.
> _______________________________________________
> 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...
>
8 months, 3 weeks