Starting SSSD without root
by Tero Saarni
Hi,
I'm trying to run SSSD inside docker container without root user. The
container is executed in OpenShift cluster which does not allow running as root
inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have
most critical parts executed as root and have it drop privileges for other
parts but this now completely blocks using SSSD in the above environment.
--
Tero
3 months, 3 weeks
file provider with multiple kerberos realms
by Techie
Main goal is to authenticate against multiple Kerberos Realms, AD domains
without joining the Linux box to AD.
We have an AD forest with 2 trusted domains and as a result 2 kerberos
realms, 1 per domain. On RHEL5,6,7 I used pam_krb5 for authentication and
passwd/group files for the user store. This allowed me to authenticate
against AD for users in the passwd file that match the KBR5 principal. In
system-auth/password-auth I would stack pam entries for each KRB5 REALM
Parent: EXAMPLE.COM
Domain1: ADA.EXAMPLE.COM
Domain2:ADB.EXAMPLE.COM
passwd user: joe_doe
krb5 principal: joe_doe(a)ADA.EXAMPLE.COM
passwd user: joe_blow
krb5 principal: joe_blow(a)ADB.EXAMPLE.COM
system-auth
auth sufficient pam_krb5.so realm=ADA.EXAMPLE.COM use_first_pass
auth sufficient pam_krb5.so realm=ADB.EXAMPLE.COM use_first_pass
In this case either joe_doe or joe_blow can log in via AD credentials and
pam would iterate through the stacked pam_krb5 entries to locate the
matching krb5 principal
I am trying to replicate this on redhat enterprise linux 8. I am aware
pam_krb5 is not an option and that sssd is the default for this use case.
What I cannot figure out is how to authenticate against multiple Domains in
SSSD. If I define 1 domain in sssd.conf with id_provider = files. I can
authenticate fine against the single domain/kerberos5 realm.
If I add multiple domains, sssd does not iterate through them, it fails if
it does not find the user in the first domain.
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = ADA.EXAMPLE.COM,ADB.EXAMPLE.COM
[pam]
#pam_local_domains = all
[domain/ADA.EXAMPLE.COM]
id_provider = files
auth_provider=krb5
krb5_server = adadc.ada.example.com
krb5_kpasswd = adadc.ada.example.com
krb5_realm = ADA.EXAMPLE.COM
dns_discovery_domain =ADA.EXAMPLE.COM
krb5_validate = false
[domain/ADB.EXAMPLE.COM
id_provider = files
auth_provider=krb5
krb5_server = adbdc.adb.example.com
krb5_kpasswd = adbdc.adb.example.com
krb5_realm =ADB.EXAMPLE.COM
dns_discovery_domain = ADB.EXAMPLE.COM
krb5_validate = false
Is what I am attempting possible without joining AD and using the provider
of AD? I would like to avoid this at all costs.
Thanks
7 months, 1 week
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.
7 months, 1 week
Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
by Alexey Tikhonov
On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd <moter(a)austin.utexas.edu> wrote:
>
> > Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
>
> Here ya go.
[sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This error code (3) stands for `DBUS_RELEASE_NAME_REPLY_NOT_OWNER ` here.
This is expected if you didn't disable systemd sssd-sudo service.
Did you have it enabled when you upgraded?
>
> I did verify on a clean install that only removing "sudo" as a service from the sssd.conf file does in fact allow it to work again. Enabling the socket does not seem to be required.
>
> Todd
>
>
> -----Original Message-----
> From: Alexey Tikhonov <atikhono(a)redhat.com>
> Sent: Monday, November 30, 2020 1:58 PM
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
>
> On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd <moter(a)austin.utexas.edu> wrote:
> >
> > Hi all
> >
> >
> >
> > I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything worked fine. Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
>
> Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
>
> >
> >
> >
> > Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of “required conf file changes” in other issues reported in github.
> >
> >
> >
> > Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
> >
> > Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
> >
> >
> >
> > I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
> >
> >
> >
> > I also noted this in the sssd-sudo man page: “It's important to note
> > that on platforms where systemd is supported there's no need to add
> > the "sudo" provider
> >
> > to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
> >
> > having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
> >
> >
> >
> > Is all of this correct? Is removing “sudo” as a service the answer to this or is it just a workaround? If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
> >
> >
> >
> > Just trying to figure out the scope of what will need to change on my fleet. The evidence so far seems to point to just removing “sudo” as a service in sssd.conf. Is that enough? Should “systemctl enable sssd-sudo” be run as well?
> >
> >
> >
> > Thanks in advance for your insights.
> >
> >
> >
> > Todd
> >
> > _______________________________________________
> > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
> > 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpoaU
> > hrE%3D&reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote
> > r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3D&
> > amp;reserved=0 List Archives:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005
> > a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236308
> > 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1Sj
> > XigQNO0orE4IY%2FRe%2FjgA%3D&reserved=0
> _______________________________________________
> 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> 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...
7 months, 3 weeks
Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
by Alexey Tikhonov
On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd <moter(a)austin.utexas.edu> wrote:
>
> Hi all
>
>
>
> I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything worked fine. Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
Could you please set "debug_level = 9" in "[sudo]" section of
/etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log
(sanitized if needed)?
>
>
>
> Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of “required conf file changes” in other issues reported in github.
>
>
>
> Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
>
> Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
>
>
>
> I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
>
>
>
> I also noted this in the sssd-sudo man page: “It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider
>
> to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
>
> having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
>
>
>
> Is all of this correct? Is removing “sudo” as a service the answer to this or is it just a workaround? If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
>
>
>
> Just trying to figure out the scope of what will need to change on my fleet. The evidence so far seems to point to just removing “sudo” as a service in sssd.conf. Is that enough? Should “systemctl enable sssd-sudo” be run as well?
>
>
>
> Thanks in advance for your insights.
>
>
>
> Todd
>
> _______________________________________________
> 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...
7 months, 3 weeks
sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
by Mote, Todd
Hi all
I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything worked fine. Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of "required conf file changes" in other issues reported in github.
Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
Removing "sudo" as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
I attempted to use "systemctl enable sssd-sudo" like the man page suggests and the result in the journal is "Dependency failed for SSSD Sudo Service responder socket."
I also noted this in the sssd-sudo man page: "It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider
to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead."
having enabled the sockect and removed "sudo" from the list of services, it does seem to work and retrieve rules from AD for the user.
Is all of this correct? Is removing "sudo" as a service the answer to this or is it just a workaround? If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it's explicitly listed as a service?
Just trying to figure out the scope of what will need to change on my fleet. The evidence so far seems to point to just removing "sudo" as a service in sssd.conf. Is that enough? Should "systemctl enable sssd-sudo" be run as well?
Thanks in advance for your insights.
Todd
7 months, 3 weeks
Re: group member denied access to directory
by Spike White
Is this a NFS mount point? If so, maybe you're hitting the "16
supplemental group" NFS inherent bug.
Spike
On Fri, Nov 20, 2020 at 2:21 PM Tung, Paul <PTung(a)mednet.ucla.edu> wrote:
> Hi,
>
>
>
> I was hoping someone on this list might be able to help.
>
> I’m getting permission denied when trying to access a directory owned by
> root, but with group that I’m a member of.
>
> I’m getting: -bash: cd: testdir: Permission denied
>
>
>
> I have the following scenario:
>
> Running CentOS Linux release 7.6.1810 and sssd 1.16.5
>
>
>
> I have a mount set up /data/testdir
>
> As root, I chown/chmod testdir:
>
> Chown root:testgrpa testdir
>
> Chmod 770 testdir
>
>
>
> When I log in as user1, I currently can’t cd into /data/testdir
>
> It gives:
>
> -bash: cd: testdir: Permission denied
>
>
>
> user1 is a member of testgrpa:
>
> OUTPUT of id user1:
>
> uid=129371342(user1) gid=129371342(user1) groups=129371342(user1)
> ,29042750285(group1),1435459822(group2),3456349245(group3),……,
> *239705249(testgrpa)*
>
>
>
> OUTPUT of getent group testgrpa:
>
> testgrpa:*: 239705249:*user1*,user2,user2,user4,…..,user50
>
>
>
>
>
> CONTENTS OF Sssd.conf:
>
> [sssd]
>
> config_file_version = 2
>
> services = nss,pam
>
> domains = dept.domain.com
>
>
>
> [nss]
>
> filter_users = root
>
> filter_groups = root
>
>
>
> [pam]
>
>
>
> [domain/dept.domai.com]
>
> id_provider = ldap
>
> auth_provider = ldap
>
> access_provider = ldap
>
> ldap_use_tokengroups = false
>
>
>
> enumerate = false
>
> cache_credentials = True
>
> case_sensitive = false
>
> ignore_group_members = false
>
> auto_private_groups = true
>
>
>
> ldap_schema = ad
>
>
>
> ldap_uri = ldaps://ldapsserver.dept.domain.com:636
>
> ldap_user_search_base = dc=ad,dc=dept,dc=domain,dc=com
>
> ldap_group_search_base = OU=Security
> Groups,OU=Groups,dc=ad,dc=dept,dc=domain,dc=com?sub?(|(cn=domain
> users)(cn=testgrpa))
>
> ldap_referrals = False
>
> ldap_group_nesting_level = 3
>
>
>
> ldap_tls_reqcert = allow
>
> ldap_tls_cacertdir = /etc/sssd
>
>
>
> ldap_use_tokengroups = True
>
> ldap_id_mapping = True
>
>
>
> override_homedir = /mnt/exports/shared/home/%u
>
> fallback_homedir = /shared/home/%u
>
>
>
> default_shell = /bin/bash
>
>
>
> ldap_access_order = filter, expire
>
> ldap_account_expire_policy = ad
>
> ldap_access_filter = (|(memberOf=cn=testgrpa,OU=Security
> Groups,OU=Groups,DC=ad,DC=dept,DC=domain,DC=com))
>
>
>
> ldap_default_bind_dn = <service account>
>
> ldap_default_authtok_type = obfuscated_password
>
> ldap_default_authtok = <authtok>
>
>
>
>
>
> Thanks,
>
>
>
> *Paul T*
>
> ------------------------------
>
> UCLA HEALTH SCIENCES IMPORTANT WARNING: This email (and any attachments)
> is only intended for the use of the person or entity to which it is
> addressed, and may contain information that is privileged and confidential.
> You, the recipient, are obligated to maintain it in a safe, secure and
> confidential manner. Unauthorized redisclosure or failure to maintain
> confidentiality may subject you to federal and state penalties. If you are
> not the intended recipient, please immediately notify us by return email,
> and delete this message from your computer.
> _______________________________________________
> 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...
>
7 months, 4 weeks
Problem with transition an user credentials through password pam-stack
by Vladimir Vakhlamov
Hello,
i would be grateful if somebody could get any advice.
My stuff and enviroment:
I have this configs on the top of all main pam-configs(just for test):
password [default=die success=ok] my_custom_pam.so
password [default=die success=done] pam_sss.so use_authtok use_first_pass
my_custom_pam.so includes two simple functions which provide correct test user credentials:
PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv) {
pam_set_item(pamh, PAM_AUTHTOK, "q1w2e3r4t5y6");
return PAM_SUCCESS;
}
PAM_EXTERN int pam_sm_chauthtok(pam_handle_t *pamh, int flags, int argc, const char **argv) {
pam_set_item(pamh, PAM_OLDAUTHTOK, "q1w2e3r4t5y6");
pam_set_item(pamh, PAM_AUTHTOK, "q1w2e3r4t5y6");
return PAM_SUCCESS;
}
Initially i worked with FreeIpa client. According to FreeIpa policy a new user should change his password during first login.
What i have is successfull auth stage, but pam_sss can't change the pass due to error server response.
...
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:auth): [DEBUG] Debug: 1, Slot: 0
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:auth): PAM_SUCCESS
Nov 27 08:35:04 test su[68635]: pam_sss(su:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/6 ruser=user rhost= user=test_user(a)dc.test
Nov 27 08:35:04 test su[68635]: pam_sss(su:auth): received for user test_user(a)dc.test: 12
Nov 27 08:35:04 test su[68635]: pam_sss(su:account): User info message:
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:chauthtok): [DEBUG] Debug: 1, Slot: 0
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:chauthtok): PRELIM
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:chauthtok): EXPIRED
Nov 27 08:35:04 test su[68635]: my_custom_pam(su:chauthtok): PAM_SUCCESS
Nov 27 08:35:04 test su[68635]: pam_sss(su:chauthtok): User info message: Old password not accepted.
Nov 27 08:35:04 test su[68635]: pam_sss(su:chauthtok): Authentication failed for user test_user(a)dc.test: 4 (System error)
...
Next time i tried to make experiment in Active Directory and i got the same result. The server can't accept user credentials.
I can't go through chauthtok prelim step because of "old user password is not accepted" and i can't get the reason why it happens.
Moveover if i remove use_first_pass parameter then pam_sss will prompt current password. In this case i enter the same password and it works and the password is changed successfully
no idea
thanks in advance
8 months
kcm, gssproxy and klist
by Winberg Adam
With KCM and gssproxy we often see a long list of credentials when doing a 'klist':
[user.u@lxserv2114 ~]$ klist
Ticket cache: KCM:17098:66803
Default principal: user.u@AD
Valid starting Expires Service principal
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
and so on...
The actual gssproxy credentials at /var/lib/gssproxy/clients/ does not correspond with this output, it only contains what could be expected - a TGT and maybe some service tickets.
The ever growing 'klist' list of credentials is a problem, after a while the user can no longer get any new credentials and therefore has no access to its NFS homedir (sec=krb5). I'm guessing it's the 'max_uid_ccaches' option in sssd-kcm that prevents this.
What is going on here - have we configured gssproxy/kcm wrong or is this a bug?
Regards
Adam
8 months
Re: primary LDAP server reconnect timeout after failover to backup
by Michael Ströder
On 11/23/20 10:23 AM, Jochen Schaefer wrote:
> I have following design problem regarding the primary LDAP server
> reconnect timeout value:
> from time to time we need to recreate the DB's of the primary ldap
> server via sync repl. Therefor we are stopping the primary LDAP,
> deleting it's db files and starting it again.
>
> The sssd client behaves as expected:
> * failover to the backup LDAP server
> * check after internal timeout 31 seconds if primary is available again
> * switch back to the primary LDAP server
>
> The problem here is - the primary is still not ready with its sync
> replication
This is a general problem with OpenLDAP taking some time in refresh
phase. Same like with any other database server and significant amount
of DB entries to be replicated during initialization.
You could also try to reduce the amount of time needed for initializing
the replica (maybe you already did). But the time period of the refresh
phase will never be zero.
I'd recommend to solve that with an operational procedure which blocks
LDAP access (e.g. with temporary host-based firewall rule) from regular
LDAP clients until monitoring shows that the replica is in sync again.
More sophistic approaches would involve using load-balancer(s) with
sophistic replica health checks.
Ciao, Michael.
8 months
