[SSSD-users] Am I blocked on sssd-users mailing list?
All, I fear I may be blocked. I responded to an email thread, with an email that had two small attachments. That was wrong. I read the mailing list by-laws and I realize that was wrong. I will not repeat that offense. As the guidelines suggest, if I need to send logs I'll post somewhere publicly and reference those URLs. But I fear my transgression seems to have blocked my email address on sssd-users mailing list. Sending this short email to confirm. Spike ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/5EMICYRTWWL47SN2RZIMSGIFLSFTUYLB/
[SSSD-users] Re: problems with sssd-1.9
I used the files located here:
https://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epel-5-x86_64/
Yes, libsss_ad.so is in the package. I used samba3x-3.6.23.
Andrea
-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Thursday, July 19, 2018 4:04 AM
To: End-user discussions about the System Security Services Daemon
Subject: {EXTERNAL} [SSSD-users] Re: problems with sssd-1.9
> On 18 Jul 2018, at 21:13, Laack, Andrea P wrote:
>
> I have been tasked with joining a number of redhat/centos 5 servers to a
> domain. I found sssd-1.9 that would allow id_provider ad. This is Centos
> 5.11.
Well, the upstream 1.9 had the ad_provider bits, but they are not built by
default IIRC, because the samba libraries on RHEL-5 were too old. You can check
by running rpm -ql sssd and checking if there is libsss_ad.so..
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe
send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwIGaQ=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ=U7-RwMM5aSl714ZiiWB9Ly-4UTAgbRqq8xuylndqN_8=kKX8OC4f8tsbUFDRZW5NTMWwPDXhi1pbl_vxtxuX0I8=UZjn24_mWi0zpXZtIwkPo3L_UffZncib2Svhf8zVMfs=
List Guidelines:
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ=U7-RwMM5aSl714ZiiWB9Ly-4UTAgbRqq8xuylndqN_8=kKX8OC4f8tsbUFDRZW5NTMWwPDXhi1pbl_vxtxuX0I8=8trw0nwPOUk21hsE0TtaDSbQp3VXeKEPs988RDVpa1w=
List Archives:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_sssd-2Dusers-40lists.fedorahosted.org_message_HOYRVOP42MLPSXEM2OM46LRKYVFY7DGP_=DwIGaQ=qhent5lL-8Lans1hhN7NTGhSd0GBLfQfwUvzHj1D5tQ=U7-RwMM5aSl714ZiiWB9Ly-4UTAgbRqq8xuylndqN_8=kKX8OC4f8tsbUFDRZW5NTMWwPDXhi1pbl_vxtxuX0I8=d058Yc__ULNnqz8Y-_ilMfPwPmGpDH8LBAa-qSRMqBc=
**
The information contained in this e-mail may be privileged and/or confidential,
and protected from disclosure, and no waiver of any attorney-client, work
product, or other privilege is intended. If you are the intended recipient,
further disclosures are prohibited without proper authorization. If you are not
the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden
and possibly a violation of federal or state law and regulations. The sender
and Baylor Scott & White Health, and its affiliated entities, hereby expressly
reserve all privileges and confidentiality that might otherwise be waived as a
result of an erroneous or misdirected e-mail transmission. No employee or agent
is authorized to conclude any binding agreement on behalf of Baylor Scott &
White Health, or any affiliated entity, by e-mail without express written
confirmation by the CEO, the Senior Vice President of Supply Chain Services or
other duly authorized representative of Baylor Scott & White Health.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ZTWXW7K2PO3PP7PJVOLYGG5MQ3TDV3UY/
[SSSD-users] Re: one user can't be looked up
> On 13 Jul 2018, at 00:16, Peter Moody wrote: > > On Wed, Jul 11, 2018 at 12:39 AM Jakub Hrozek wrote: >> >> On Tue, Jul 10, 2018 at 08:14:15PM -0700, Peter Moody wrote: >>> line breaks are in the original logs: >> >> Right, I saw this, but can I see more context earlier in the logs? See >> inline.. > > attached. > > this is everything from sss_cache -E, to after 'id peter' returns info > for user pmoody > >> Could it be the user itself? I don't know exactly, that's why I asked >> for more context.. > > it could be. I posted the current ldif's for both users in the first > message. is there something else I should be looking? Thank you for the logs, they show now clearly where the issue is happening, it looks like when setting the attributes for the user the user is not cached yet, which sounds bizzare because the user is looked up in the function before. But I’m afraid that without stepping through the code with a debugger I won’t be able to find the reason..I guess I could add a patch with more debug data if you can apply it yourself (sorry, I have no idea how to patch a debian package) but currently the logs are not as helpful as I thought. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DN6UKB5NX4CWZIZGMFVU4DDRT6C3M2LP/
[SSSD-users] Re: sss_override and ssh keys
> On 11 Jul 2018, at 15:28, John Hearns wrote: > > I have set up an sss_override for my user account > > johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash > > I also have an entry in the locla /etc/passwd file. > When I ssh to a server running sssd my ssh key is accepted. > > When I have no local /etc/passwd > When I ssh to a server running sssd my ssh key is not used and I am prompted > for a password Is that a local SSH key stored in the user’s home or in LDAP? If a local one, then I think the only important thing is to tell SSH where to look at, so the homedir must be correct and of course the user must have the correct UID and GID to be allowed to enter that homedir. > > Can anyone explain please? > > The answer will be along the lines of at what stage in the ssh login the > override is being 'honoured' > However this is a bit of a major problem. I guess also I will be told that I > have done something wrong. > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ARZQMHUEUBXR53P7XG5QSFMDU6KHBK3O/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DL67YE2ZEIQ5LY2UCIVRRW5U7DLM7LMZ/
[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)
> On 13 Jul 2018, at 17:40, Spike White wrote: > > Jakub, > > Thank you to answering so promptly. > > We are currently testing this in a lab before full deployment, so I have some > degree of time before we deploy sssd in a bigger context. If you would > prefer for me to work with you directly off-line, please advise. As an > example, the attached sssd_amer.dell.com.log file was originally 40 MB. (I > presume because of debugging level). Out of respect for others on the > mailing list, I severely trimmed the log file to only the lines of interest > (I hope). But it's entirely possible I may have over-trimmed. > I’m afraid so, because the logs say: (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [tokenGroups] …. and I’m really interested in this part :-) (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [admpatrick_whee...@amer.dell.com] ... (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use associated map > You asked: > Can you send logs for a single lookup of "id username" with tokengroups > enabled? > > Attached are the logs. sssd_amer.dell.com.log and sssd_nss.log, for this > lookup: > >[root@spikerealmd02 sssd]# id admpatrick_wheeler >uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > groups=2604370(admpatrick_wheeler),1010(amerunixusers) > > This is with ldap_use_tokengroups = True, so the above lookup is incorrect. > > What it should show is: > id admpatrick_wheeler > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers) > > You asked: >Why do you disable the subdomains provider? Isn't it easier to just list >the domains you want to enable using the ad_enabled_domains option? > >btw this can actually cause issues because the subdomains provider is >needed to fetch the joined domain SID at least, among other things. > > When I ran with: > ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, > japn.dell.com, dell.com > > it broke cross-subdomain authentication. that is, I could resolve accounts > from the local domain (AMER), but not from any other domain (like apac). > When I reviewed the logs, I saw the sssd_nss.log would do a dispatch to the > apac.dell.com child, but the dispatch would always fail. > > In sssd_apac.dell.com.log -- the dispatch was never picked up. Interesting, do you still have the logs around? > > I also noticed that sssctl domain-list gave me this: > amer.dell.com > apac.dell.com > emea.dell.com > japn.dell.com > dell.com > amer.dell.com > apac.dell.com > emea.dell.com > japn.dell.com Including the duplicate domains? That sounds like a bug.. > > I suspect that sssd_nss was attempting to dispatch into this apac.dell.com > "ghost" domain and failing. When I removed ad_enabled_domains (& commented > out dell.com as a domain), I noticed sssctl domain-list gave me the expected: > > amer.dell.com > apac.dell.com > emea.dell.com > japn.dell.com > > And cross-subdomain authentication worked (modulo this tokengroups problem > where not all groups show up when tokengroups == True). > > You stated: > > ldap_schema = rfc2307bis > > Please don't set ldap_schema to anything else than 'ad' (the default) with > id_provider=ad. > > Unfortunately, our erstwhile AD administrators when they extended our AD > schema years ago did not use an rfc2307 schema extension. They used a > rfc2307bis schema extension instead. > > I had fits with even basic sssd AD integration until I realized this. (I > thought I was going to have to manually set up ldap_filters for the few > quirky LDAP attributes associated with an account, but then I realized this > conformed 100% to rfc2307bis.) When I set ldap_schema to rfc2307bis, the > basic (same domain) authentication worked (without tokengroups). > I meant something else. Internally in SSSD, ldap_schema=ad is a superset of rfc2307bis with some defaults tuned to be AD-specific. And the AD provider really does not expect the schema to be set to anything else, moreover there are some branches in the underlying LDAP provider (the AD provider is a wrapper around the LDAP provider more or less) that check if the schema is set to “ad” to follow some AD specific branch. > Spike > > On Tue, Jul 10, 2018 at 9:59 AM Jakub Hrozek wrote: > On Mon, Jul 09, 2018 at 03:11:38PM -0500, Spike White wrote: > > All, > > > > Below is a writeup of missing AD groups for accounts when using > > tokengroups. When not using tokengroups, sssd is rock solid. > > > > Yes, most of the missing AD groups are universal or global groups -- but > > not all! For
[SSSD-users] Re: Problem with kinit
> On 16 Jul 2018, at 11:48, John Hearns wrote: > > I have had my head inside the ldap_child.c source code all morning. > I am getting these errors logged: > > [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/ > i...@nzww.nzcorp.net' not found in Kerberos database This is expected, in AD the host/fqdn principal cannot be used to get a TGT. As you can see below, you are using the netbiosname$@realm principal to kinit which works fine. If your configuration is using id_provider=ad I would have expected sssd to prefer the netbiosname$ principal, but if the selection fails or you are using the ldap provider, you can help sssd with the ldap_sasl_authid parameter. > > However the dialy ksktutil cron job I have running completes OK, and msktutil > --auto-update tells me the machine password was renewed two days ago. > > Here is what happens when I run kinit from the command line. > My workstation is called ibis. Please someone hit me with a clue stick. > > # kinit -k > kinit: Client 'host/i...@nzww.nzcorp.net' not found in Kerberos database > while getting initial credentials > > # kinit -V -k ibis$ > Using default cache: /tmp/krb5cc_0 > Using principal: ibis$@NZWW.NZCORP.NET > Authenticated to Kerberos v5 > > # kinit -V -k IBIS\$@NZWW.NZCORP.NET > Using default cache: /tmp/krb5cc_0 > Using principal: IBIS$@NZWW.NZCORP.NET > Authenticated to Kerberos v5 > > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/4DY3TSRSJBV5AU2P3CQH2UHH7GHXLOLV/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BPEL355LXLAJ4ZI7UVSFHJ5ZG6CUJIWI/
[SSSD-users] Re: problems with sssd-1.9
> On 18 Jul 2018, at 21:13, Laack, Andrea P wrote: > > I have been tasked with joining a number of redhat/centos 5 servers to a > domain. I found sssd-1.9 that would allow id_provider ad. This is Centos > 5.11. Well, the upstream 1.9 had the ad_provider bits, but they are not built by default IIRC, because the samba libraries on RHEL-5 were too old. You can check by running rpm -ql sssd and checking if there is libsss_ad.so.. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HOYRVOP42MLPSXEM2OM46LRKYVFY7DGP/
[SSSD-users] sss_override and ssh keys
I have set up an sss_override for my user account johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash I also have an entry in the locla /etc/passwd file. When I ssh to a server running sssd my ssh key is accepted. When I have no local /etc/passwd When I ssh to a server running sssd my ssh key is not used and I am prompted for a password Can anyone explain please? The answer will be along the lines of at what stage in the ssh login the override is being 'honoured' However this is a bit of a major problem. I guess also I will be told that I have done something wrong. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ARZQMHUEUBXR53P7XG5QSFMDU6KHBK3O/
[SSSD-users] Problem with kinit
I have had my head inside the ldap_child.c source code all morning. I am getting these errors logged: [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/ i...@nzww.nzcorp.net' not found in Kerberos database However the dialy ksktutil cron job I have running completes OK, and msktutil --auto-update tells me the machine password was renewed two days ago. Here is what happens when I run kinit from the command line. My workstation is called ibis. Please someone hit me with a clue stick. # kinit -k kinit: Client 'host/i...@nzww.nzcorp.net' not found in Kerberos database while getting initial credentials # kinit -V -k ibis$ Using default cache: /tmp/krb5cc_0 Using principal: ibis$@NZWW.NZCORP.NET Authenticated to Kerberos v5 # kinit -V -k IBIS\$@NZWW.NZCORP.NET Using default cache: /tmp/krb5cc_0 Using principal: IBIS$@NZWW.NZCORP.NET Authenticated to Kerberos v5 ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/4DY3TSRSJBV5AU2P3CQH2UHH7GHXLOLV/
[SSSD-users] Re: problems with sssd-1.9
[domain\xxx.pvt] Is the backslash valid here? I am sure an expert will say yes.. You are well aware that RHEL 5 is out of support lifetime? I would imagine that you have some critical applications which run on these machines though. From: Laack, Andrea P Sent: 18 July 2018 21:13:47 To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] problems with sssd-1.9 I have been tasked with joining a number of redhat/centos 5 servers to a domain. I found sssd-1.9 that would allow id_provider ad. This is Centos 5.11. Here is what I got: [root@testcentos5 db]# /usr/sbin/sssd -i -d9 (Wed Jul 18 13:18:49:136142 2018) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! (Wed Jul 18 13:18:49:137532 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Jul 18 13:18:49:137857 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:137962 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138029 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138161 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138226 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138343 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138404 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138502 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138660 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [sssd] (Wed Jul 18 13:18:49:138784 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [config_file_version] (Wed Jul 18 13:18:49:138870 2018) [sssd] [confdb_create_ldif] (0x4000): config_file_version: 2 (Wed Jul 18 13:18:49:138945 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [domains] (Wed Jul 18 13:18:49:139034 2018) [sssd] [confdb_create_ldif] (0x4000): domains: xxx.pvt (Wed Jul 18 13:18:49:139130 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [services] (Wed Jul 18 13:18:49:139214 2018) [sssd] [confdb_create_ldif] (0x4000): services: nss, pam (Wed Jul 18 13:18:49:139295 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:139374 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:139539 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=sssd,cn=config cn: sssd config_file_version: 2 domains: xxx.pvt services: nss, pam debug_level: 9 (Wed Jul 18 13:18:49:139873 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [nss] (Wed Jul 18 13:18:49:139972 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:140046 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:140113 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=nss,cn=config cn: nss debug_level: 9 (Wed Jul 18 13:18:49:140193 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [domain\xxx.pvt] (Wed Jul 18 13:18:49:140280 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [fallback_homedir] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): fallback_homedir: /home/%u (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [default_shell] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): default_shell: /bin/bash (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ad_domain] (Wed Jul 18 13:18:49:140377 2018) [sssd] [confdb_create_ldif] (0x4000): ad_domain: xxx.pvt (Wed Jul 18 13:18:49:140453 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_realm] (Wed Jul 18 13:18:49:140536 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_realm: xxx.PVT (Wed Jul 18 13:18:49:140613 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_server] (Wed Jul 18 13:18:49:140690 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_server: c02.xxx.pvt (Wed Jul 18 13:18:49:140765 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [auth_provider] (Wed Jul 18 13:18:49:140842 2018) [sssd] [confdb_create_ldif] (0x4000): auth_provider: krb5 (Wed Jul 18 13:18:49:141316 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [cache_credentials] (Wed Jul 18 13:18:49:141640 2018) [sssd] [confdb_create_ldif] (0x4000): cache_credentials: True (Wed Jul 18 13:18:49:141839 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [id_provider] (Wed Jul 18 13:18:49:141945 2018) [sssd] [confdb_create_ldif] (0x4000): id_provider: ad (Wed Jul 18 13:18:49:142023 2018) [sssd] [confdb_create_ldif] (0x0400):
