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
2 weeks
sssd performance on large domains
by zfnoctis＠gmail.com
Hi,
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
2 years, 2 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
2 years, 4 months
Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Spike White
Sssd experts,
*Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ process? We have ~0.4% of our Linux servers dropping
off the AD domain monthly.
*Longer explanation:*
Over the past two years, we have on-boarded sssd as our Linux AD
integration component. Largely displacing a former commercial product that
did the same.
We have about ~20K Linux servers that are sssd-enabled. A mix of RHEL6,
RHEL7, RHEL8, Oracle Linux 6, 7 and 8. We have ~7K Linux servers still on
the old commercial product. (For certain edge-case scenarios, such as
DMZs, the commercial product works better.)
Our AD forest is a single AD forest, with 4 regional child domains. All
with transitive trust. Sssd auto-discovers parent domain and all 4 child
domains, no problem – whenever it’s adcli joined to its regional local
domain.
Why are I writing this?
Because we are researching an ongoing problem reported by L1 server ops.
About 70 – 80 sssd-enabled Linux servers / month drop off the domain. Out
of our current sssd-enabled population of ~20K server, that’s not
horrible. But still it should be better. (Our former commercial product
did better.)
It’s not limited to one particular OS, OS version, build location or
region. We have surveyed; it seems to occur randomly among all OS
versions, regions and locations.
To be clear, it’s extremely likely that this behavior arising from some
subtle misconfiguration on our part – not from any sssd or adcli or
Kerberos bug. We have a couple of configuration improvements we’re
pursuing. (Kerberos max ticket lifetime mismatch between AD and
/etc/krb5.conf file for instance.)
We are taking sssd’s default settings for
ad_maximum_machine_account_password_age and
ad_machine_account_password_renewal_opts. So after 30 days, sssd will
attempt daily to renew the host Kerberos keytab file. It should re-attempt
daily if not renewed. By company policy, our AD disables any machine
accounts that have not renewed their credentials in 40 days. So when we
find servers that have dropped off the domain, it’s because they have not
renewed their AD machine accounts in 40 days.
We have SR’s open with our OS vendors (Redhat and Oracle respectively) for
months now. To no great help. (They gave a few suggestions, but none
panned out.)
We thought we were hitting this bug:
https://github.com/SSSD/sssd/issues/4762
But packet captures proved that adcli update is using TCP on RHEL7/8.
Thus, this might be a potential problem, but only on RHEL6. (BTW
‘udp_preference_limit = 0’ doesn’t force use of TCP for the kpasswd
invocation in RHEL6 – it still uses UDP. Thus, the recommended work-around
for this bug doesn’t work.)
So that isn’t our underlying problem.
We’re at a loss now – as you can see, we’re grasping at straws.
How can we troubleshoot sssd’s ‘automatic Kerberos Host keytab renewal’
process? Whenever we inspect a particular server it works. We can’t run
all sssd clients at debug level 9; it fills up /var/log filesystem after a
few days of that. We’re interested in troubleshooting that one particular
sssd process on all clients; not all parts of sssd.
Other than a steep learning curve (on our part), obscure situations (like
DMZ auto-discovery of AD controllers) and exotic scenarios (like above),
we’re quite happy with our 2 yr journey of direct AD integration with
sssd. Obviously, the troubleshooting tools on RHEL6 are very minimal.
But certainly, overall the quality of sssd on RHEL7/8 is excellent. AD
integration has innumerable devils in the details; I’m amazed that sssd
performs as well as it does against our multi-domain forest.
Spike
PS the problem with sssd auto-discovery of AD controllers in DMZs has been
fixed in a recent sssd release. The better discovery algorithm was
implemented – same one used by Windows clients and commercial products.
It’s just that recent sssd version is not on RHEL7 or 8.
2 years, 6 months
Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz
So i think you just want:
kinit -R -k $HOSTNAME$
On 8/30/21 11:28 AM, Mote, Todd wrote:
> I wrote that from memory. What's needed is the shortname and a $, but thinking more about it now, that's needed at the end of the shortname not the beginning.
>
> -----Original Message-----
> From: Patrick Goetz <pgoetz(a)math.utexas.edu>
> Sent: Monday, August 30, 2021 11:25 AM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
>
> Todd,
>
> On 8/27/21 9:41 AM, Mote, Todd wrote:
>> We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We haven't had computers falling off the domain since we implemented that.
>>
>
> Are you sure about this syntax? Adding a -s flag in $( ) containing a bash variable doesn't do anything.
>
> _______________________________________________
> 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...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>>> 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...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf. <<
2 years, 7 months
Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz
Todd,
On 8/27/21 9:41 AM, Mote, Todd wrote:
> We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We haven't had computers falling off the domain since we implemented that.
>
Are you sure about this syntax? Adding a -s flag in $( ) containing a
bash variable doesn't do anything.
2 years, 7 months
Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Spike White
Todd,
I confess I don't completely understand your solution. I get that
configuration management tools use the passwordlastset attribute with a
value that's greater than XX days to cull objects. My Windows server
engineering counterparts have a scheduled job that deletes all machine
accounts from their Windows OU where passwordlastset attribute > 60 days
and server not pingable. (Actually, it moves the machine account to an
archival OU and then deletes it from archival OU if a Windows SE hasn't
moved it back in 90 days).
Also, by policy our AD forest locks all machine accounts where
passwordlastset attribute > 40 days.
So I get that part.
But you said:
We ultimately decided to deploy a cron job with the install that ran
periodically (less than the renewal period) to keep the keytab fresh (kinit
-R -k $($hostname -s)).
I get what this is doing. Actually, sssd typically uses the service
principal 'host/<fqdn>@<DOMAIN>'. For example: host/
austgcore17.us.example.com(a)AMER.EXAMPLE.COM. So I would do this:
kinit -R -k host/austgcore17.us.example.com(a)AMER.EXAMPLE.COM
or (even simpler):
kinit -R -k
since kinit appears to assume this host/ service principal if you don't
specify it. What you're doing is refresh the host's Kerberos TGT ticket.
Actually, you're doing it for your cron job only -- sssd seems to store
its host credential in
cache FILE:/var/lib/sss/db/ccache_AMER.EXAMPLE.COM_VgdSdK or some such.
So you're renewing your host's TGT ticket. But by default, the max
lifetime for a TGT ticket is 24hrs (our AD DCs allow max 10 hrs -- that's
pretty std recommendation for AD). And your max renewal lifetime is 7 days
by default. After that, you'd have to get a fresh kerberos TGT ticket.
So are you completely disabling sssd's automatic machine account password
renewal (by setting ad_maximum_machine_account_password_age = 0)? And then
you're never changing your machine account passwords ever; your cron job
is just refreshing your host's TGT ticket every 9 hrs or so for 7 days?
I'm not fully following the explanation of your approach.
Also, machine account passwords are related to kerberos keytab entries.
For a machine account, a Kerberos keytab entry is the machine account
password (encrypted) with other relevant information, such as timestamp,
KVNO, service principal name and encryption type. The machine account
password stored in AD (with a particular msDS-KeyVersionNumber) must change
the corresponding /etc/krb5.keytab entry (with the same KVNO number).
That's how this client authenticates to Kerberos (AD) that it's who it
claims to be.
Spike
On Fri, Aug 27, 2021 at 9:41 AM Mote, Todd <moter(a)austin.utexas.edu> wrote:
> As a follow on to that, to keep themselves clear of debris, configuration
> management tools use the passwordlastset attribute with a value that's
> greater than XX days to cull objects as well. We had similar issues when
> we first implemented SSSD several years ago too. We ultimately decided to
> deploy a cron job with the install that ran periodically (less than the
> renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We
> haven't had computers falling off the domain since we implemented that.
>
> Isn’t the issue that the keytab expires and is not renewed in time, then
> the computer can't change its password because the domain can't verify the
> keytab? Also, aren't machine passwords different from Kerberos keytabs?
> Related, because a machine can't change it's password if it can't prove who
> it is via Kerberos and the keytab. I just want to make sure those aren't
> being conflated. Similarly, a computer can't update it's DNS record in the
> domain with out Kerberos, so similarly, if the keytab is not kept fresh,
> little domain object maintenance can happen, because Kerberos is stale.
>
> Computer account password changes are always initiated by clients, not the
> domain, even on windows.
>
> Todd
>
> -----Original Message-----
> From: James Ralston <ralston(a)pobox.com>
> Sent: Thursday, August 26, 2021 10:31 PM
> To: End-user discussions about the System Security Services Daemon <
> sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
> Keytab Renewal’ with AD back-end….
>
> On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark <mark.christian(a)intel.com>
> wrote:
> > [W]hy bother with updating the machine account password?
>
> For sites that have a lot of machine churn, where machine accounts aren't
> reliably purged from AD when the underlying host is decommissioned,
> disabling and/or purging machine accounts with old passwords is essentially
> a garbage collection activity, to prevent stale machine accounts from
> continuing to exist in AD in perpetuity.
>
> Also, some sites must conform with security guidelines that *require*
> frequent changes of machine account passwords:
>
>
> https://www.stigviewer.com/stig/microsoft_windows_server_2016/2021-03-05/...
>
> Granted, that STIG rule applies to Windows machine accounts, not Linux
> machine accounts, but disabling any machine account in AD whose password is
> older than 30 days is one way to detect any Windows clients that are
> nonconforming with the STIG. And in many cases it's easier to apply that
> rule globally than on a per-OU basis (to exempt non-Windows machine
> accounts).
> _______________________________________________
> 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...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >> 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...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
2 years, 7 months
ldap client configuration in sssd.conf to query views
by iulian roman
Hello,
I try to configure some old sssd clients to connect to IPA server which does use AD and views. Is there any documentation which points which ldap_* related variables needs to be configured in sssd,conf in order to be able to query the views in IPA server ?
Currently I can run ldapsearch -Y GSSAPI -h ipaserver.ipa.example.com -b "cn=legacy_servers,cn=views,cn=accounts,dc=example,dc=com" and it does display all the data, but I want that to be configured automatically at sssd level.
2 years, 8 months
One slight enhancement to sssctl user-checks...
by Spike White
All,
sssctl user-check is very good. In particular, when you want to see if a
particular user is conferred access, you look for the:
pam_acct_mgmt: Success
or the:
pam_acct_mgmt: Permission denied
lines.
But often, users are members of multiple various groups. It's often
difficult to track down which of the particular groups or user entries are
actually conferring the access to the user.
It would be nice to output on success, which user or group is conferring
the login access.
I'm not saying it needs to be exhaustive. I.e., no need to parse every
group to see which groups.
But sssctl at that point in time has determined (based on some rule) that
login access is permitted. Just output whatever that matching rule is.
If you wanted this additional output only in a verbose mode, that'd be
fine.
I suppose I could probably turn on debug level on sssd, restart it and grub
through all the sssd log files to find which user or group conferred
access. But that'd be painful. Usually I construct a list of all AD
groups this individual is a member of (often it's 15-20). Then which of
these groups are UNIX-enabled in AD. Then of those, which are permitted.
Spike
2 years, 8 months
Server not found in Kerberos database
by Jovan Quinones-Morales
Hello!
I am looking at some errors that I have been seeing in some logs specific
to but not limited to RHEL/CentOS 7.x 8.x and Rocky 8.x (SSSD version
- sssd-2.4.0-9.el8_4.1.x86_64). All systems are attached to a Windows
Active Directory domain using 'adcli'.
The configuration works as expected and seems to see no major problems.
Although it does cause some unnecessary noise in the logs. Which prompted
me to look at it a little further.
All the logs show the errors that are happening. FYI: Servers are part of a
forest and it does look like rdns = false.
Here are all the logs related to the error (If I am missing anything
please let me know and I will add it in there ASAP! Some logs are
compressed as it repeats itself over and over again.
****Command Used: journalctl -p 4****
Aug 10 10:28:33 EXAMPLE.CC.CC.NET sssd[ldap_child[2972536]][2972536]:
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM' not found in Kerberos
database. Unable to create GSSAPI-encrypted LDAP connection.
Aug 10 10:28:33 EXAMPLE.CC.CC.NET sssd[ldap_child[2972537]][2972537]:
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM' not found in Kerberos
database. Unable to create GSSAPI-encrypted LDAP connection.
Aug 10 10:28:33 EXAMPLE.CC.CC.NET sssd[ldap_child[2972538]][2972538]:
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM' not found in Kerberos
database. Unable to create GSSAPI-encrypted LDAP connection.
Aug 10 10:28:33 EXAMPLE.CC.CC.NET sssd[ldap_child[2972539]][2972539]:
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM' not found in Kerberos
database. Unable to create GSSAPI-encrypted LDAP connection.
Aug 10 10:28:33 EXAMPLE.CC.CC.NET sssd[ldap_child[2972540]][2972540]:
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM' not found in Kerberos
database. Unable to create GSSAPI-encrypted LDAP connection.
****Command Used: journalctl -u sssd****
Aug 09 14:28:32 EXAMPLE.CC.CC.NET sssd[3906155]: tkey query failed: GSSAPI
error: Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Server not found in Kerberos database.
Aug 09 14:28:32 EXAMPLE.CC.CC.NET sssd[3906155]: tkey query failed: GSSAPI
error: Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Server not found in Kerberos database.
Aug 09 14:28:32 EXAMPLE.CC.CC.NET sssd[3906155]: tkey query failed: GSSAPI
error: Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Server not found in Kerberos database.
Aug 09 14:28:32 EXAMPLE.CC.CC.NET sssd[3906155]: tkey query failed: GSSAPI
error: Major = Unspecified GSS failure. Minor code may provide more
information, Minor = Server not found in Kerberos database.
Aug 09 14:40:52 EXAMPLE.CC.CC.NET adcli[2526663]: GSSAPI client step 1
Aug 09 14:40:52 EXAMPLE.CC.CC.NET adcli[2526663]: GSSAPI client step 1
Aug 09 14:40:52 EXAMPLE.CC.CC.NET adcli[2526663]: GSSAPI client step 1
****KEYTAB****
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
2 MYSERVER$(a)EXAMPLE.DOMAIN.COM
2 MYSERVER$(a)EXAMPLE.DOMAIN.COM
2 host/MYSERVER(a)EXAMPLE.DOMAIN.COM
2 host/MYSERVER(a)EXAMPLE.DOMAIN.COM
2 host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM
2 host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM
2 RestrictedKrbHost/MYSERVER(a)EXAMPLE.DOMAIN.COM
2 RestrictedKrbHost/MYSERVER(a)EXAMPLE.DOMAIN.COM
2 RestrictedKrbHost/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM
2 RestrictedKrbHost/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM
****KRB5_CHILD.LOG****
(2021-08-10 13:59:37): [krb5_child[3051214]] [sss_send_pac] (0x0040):
sss_pac_make_request failed [-1][2].
(2021-08-10 13:59:37): [krb5_child[3051214]] [validate_tgt] (0x0040):
sss_send_pac failed, group membership for user with principal [someuser1\@
EXAMPLE.DOMAIN.COM(a)EXAMPLE.DOMAIN.COM] might not be correct.
(2021-08-10 14:24:43): [krb5_child[3061023]] [sss_send_pac] (0x0040):
sss_pac_make_request failed [-1][2].
(2021-08-10 14:24:43): [krb5_child[3061023]] [validate_tgt] (0x0040):
sss_send_pac failed, group membership for user with principal [someuser1\@
EXAMPLE.DOMAIN.COM(a)EXAMPLE.DOMAIN.COM] might not be correct.
****LDAP_CHILD.LOG****
(2021-08-10 14:28:33): [ldap_child[3063821]] [ldap_child_get_tgt_sync]
(0x0040): krb5_get_init_creds_keytab() failed: -1765328378
(2021-08-10 14:28:33): [ldap_child[3063821]] [ldap_child_get_tgt_sync]
(0x0010): Failed to initialize credentials using keytab
[MEMORY:/etc/krb5.keytab]: Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM'
not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP
connection.
(2021-08-10 14:28:33): [ldap_child[3063821]] [main] (0x0020):
ldap_child_get_tgt_sync failed.
(2021-08-10 14:28:33): [ldap_child[3063822]] [ldap_child_get_tgt_sync]
(0x0040): krb5_get_init_creds_keytab() failed: -1765328378
(2021-08-10 14:28:33): [ldap_child[3063822]] [ldap_child_get_tgt_sync]
(0x0010): Failed to initialize credentials using keytab
[MEMORY:/etc/krb5.keytab]: Client 'host/EXAMPLE.CC.CC.NET(a)EXAMPLE.DOMAIN.COM'
not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP
connection.
(2021-08-10 14:28:33): [ldap_child[3063822]] [main] (0x0020):
ldap_child_get_tgt_sync failed.
****SSSD.CONF****
[sssd]
domains = EXAMPLE.domain.com
config_file_version = 2
services = nss, pam
[domain/EXAMPLE.domain.com]
ad_domain = EXAMPLE.domain.com
ad_enable_gc = false
krb5_realm = EXAMPLE.DOMAIN.COM
krb5_lifetime = 10h
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = true
ldap_purge_cache_timeout = 0
realmd_tags = joined-with-adcli, manages-system
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = true
default_shell = /bin/bash
ldap_id_mapping = true
ldap_sasl_authid = MYSERVER$(a)EXAMPLE.DOMAIN.COM
ldap_use_tokengroups = true
use_fully_qualified_names = false
fallback_homedir = /home/%d/%u
access_provider = simple
Simple_allow_groups = linux_admins
simple_allow_users = someuser1, someuser2, someuser3
Thank you so much for your help!
--
*Jovan Quinones-Morales*
Linux Operating Systems Analyst
VCU Infrastructure Services <https://www.ucc.vcu.edu/>
Technology Services Department
804.828.4810
quinonesmoj(a)vcu.edu
<https://adminmicro2.questionpro.com/?t_340030260=Jovan%20Quinones-Morales...>
*Don't be a phishing victim -- VCU and other reputable organisations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details,
visit **https://ts.vcu.edu/about-us/information-security/common-questions/what-is-phishing
<https://ts.vcu.edu/about-us/information-security/common-questions/what-is...>*
2 years, 8 months
