Re: problems with sssd-1.9
by Jakub Hrozek
> On 18 Jul 2018, at 21:13, Laack, Andrea P <Andrea.Laack(a)BSWHealth.org> 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..
5 years, 9 months
Problem with kinit
by John Hearns
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/
IBIS(a)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/ibis(a)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$(a)NZWW.NZCORP.NET
Authenticated to Kerberos v5
# kinit -V -k IBIS\$(a)NZWW.NZCORP.NET
Using default cache: /tmp/krb5cc_0
Using principal: IBIS$(a)NZWW.NZCORP.NET
Authenticated to Kerberos v5
5 years, 9 months
Re: problems with sssd-1.9
by JOHE (John Hearns)
[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 <Andrea.Laack(a)BSWHealth.org>
Sent: 18 July 2018 21:13:47
To: sssd-users(a)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: xxxxc02.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): Processing attribute [ad_server]
(Wed Jul 18 13:18:49:142102 2018) [sssd] [confdb_create_ldif] (0x4000): ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03
(Wed Jul 18 13:18:49:142186 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_store_password_if_offline]
(Wed Jul 18 13:18:49:142267 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_store_password_if_offline: True
(Wed Jul 18 13:18:49:142344 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [access_provider]
(Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x4000): access_provider: simple
(Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_schema]
(Wed Jul 18 13:18:49:142435 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_schema: ad
(Wed Jul 18 13:18:49:142518 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_id_mappings]
(Wed Jul 18 13:18:49:142599 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_id_mappings: True
(Wed Jul 18 13:18:49:142675 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_groups]
(Wed Jul 18 13:18:49:142753 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_groups: linux@admins(a)xxx.pvt
(Wed Jul 18 13:18:49:142829 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_users]
(Wed Jul 18 13:18:49:142922 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_users: rapid7scan(a)xxx.pvt
(Wed Jul 18 13:18:49:143005 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level]
(Wed Jul 18 13:18:49:143079 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9
(Wed Jul 18 13:18:49:143166 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn
dn: cn=domain\xxx.pvt,cn=config
cn: domain\xxx.pvt
fallback_homedir: /home/%u
default_shell: /bin/bash
ad_domain: xxx.pvt
krb5_realm: XXX.PVT
krb5_server: xxx02.xxx.pvt
auth_provider: krb5
cache_credentials: True
id_provider: ad
ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03
krb5_store_password_if_offline: True
access_provider: simple
ldap_schema: ad
ldap_id_mappings: True
simple_allow_groups: linux@admins(a)xxx.pvt
simple_allow_users: rapid7scan(a)xxx.pvt
debug_level: 9
(Wed Jul 18 13:18:49:143281 2018) [sssd] [confdb_init_db] (0x1000): LDIF file to import:
dn: cn=config
version: 2
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
domains: xxx.pvt
services: nss, pam
debug_level: 9
dn: cn=nss,cn=config
cn: nss
debug_level: 9
dn: cn=domain\bhcs.pvt,cn=config
cn: domain\bhcs.pvt
fallback_homedir: /home/%u
default_shell: /bin/bash
ad_domain: xxx.pvt
krb5_realm: XXX.PVT
krb5_server: xxxxxdc02.xxx.pvt
auth_provider: krb5
cache_credentials: True
id_provider: ad
ad_server: xxxxxc01, xxxxxc01, xxxxxc01, xxxxxc02, xxxxxc03
krb5_store_password_if_offline: True
access_provider: simple
ldap_schema: ad
ldap_id_mappings: True
simple_allow_groups: linux@admins(a)xxx.pvt
simple_allow_users: rapid7scan(a)xxx.pvt
debug_level: 9
(Wed Jul 18 13:18:49:143420 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143639 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143862 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143983 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144062 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144166 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144275 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144372 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144520 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144805 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:158827 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0)
(Wed Jul 18 13:18:49:159670 2018) [sssd] [add_implicit_services] (0x0040): id_provider is not set for domain [xxx.pvt], trying next domain.
(Wed Jul 18 13:18:49:159863 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [xxx.pvt]
(Wed Jul 18 13:18:49:159970 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [xxx.pvt], skipping!
(Wed Jul 18 13:18:49:160014 2018) [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error!
(Wed Jul 18 13:18:49:160068 2018) [sssd] [get_monitor_config] (0x0010): No domains configured.
(Wed Jul 18 13:18:49:160179 2018) [sssd] [main] (0x0020): Error loading configuration database: [2]: No such file or directory
Sssd.conf
[sssd]
config_file_version = 2
domains = bhcs.pvt
services = nss, pam
debug_level = 9
[nss]
debug_level = 9
[domain\xxx.pvt]
fallback_homedir = /home/%u
default_shell = /bin/bash
ad_domain = xxx.pvt
krb5_realm = xxx.PVT
krb5_server = xxxxc02.bhcs.pvt
auth_provider = krb5
cache_credentials = True
id_provider = ad
ad_server = xxxxc01, xxxxc01, xxxxdc01, xxxxdc02, xxxxc03
krb5_store_password_if_offline = True
access_provider = simple
ldap_schema = ad
ldap_id_mappings = True
# ldap_sasl_mech=GSSAPI
simple_allow_groups = linux@admins(a)xxx.pvt
simple_allow_users = rapid7scan(a)xxx.pvt
debug_level = 9
Would appreciate any assistance you could offer.
Thanks
Andrea
Andrea Laack
Host Systems
[cid:image002.jpg@01D41EA1.8969FEA0]
2401 S. 31st Street
Temple, TX 76508
Mailstop: MS-2-1.41
Office: 254-724-9490
andrea.laack(a)bswhealth.org<mailto:andrea.laack@bswhealth.org>
[cid:image003.png@01D41EA0.4137E5D0] <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yo...> [cid:image004.png@01D41EA0.4137E5D0]
________________________________
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.
5 years, 9 months
problems with sssd-1.9
by Laack, Andrea P
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: xxxxc02.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): Processing attribute [ad_server]
(Wed Jul 18 13:18:49:142102 2018) [sssd] [confdb_create_ldif] (0x4000): ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03
(Wed Jul 18 13:18:49:142186 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_store_password_if_offline]
(Wed Jul 18 13:18:49:142267 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_store_password_if_offline: True
(Wed Jul 18 13:18:49:142344 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [access_provider]
(Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x4000): access_provider: simple
(Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_schema]
(Wed Jul 18 13:18:49:142435 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_schema: ad
(Wed Jul 18 13:18:49:142518 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_id_mappings]
(Wed Jul 18 13:18:49:142599 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_id_mappings: True
(Wed Jul 18 13:18:49:142675 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_groups]
(Wed Jul 18 13:18:49:142753 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_groups: linux@admins(a)xxx.pvt
(Wed Jul 18 13:18:49:142829 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_users]
(Wed Jul 18 13:18:49:142922 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_users: rapid7scan(a)xxx.pvt
(Wed Jul 18 13:18:49:143005 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level]
(Wed Jul 18 13:18:49:143079 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9
(Wed Jul 18 13:18:49:143166 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn
dn: cn=domain\xxx.pvt,cn=config
cn: domain\xxx.pvt
fallback_homedir: /home/%u
default_shell: /bin/bash
ad_domain: xxx.pvt
krb5_realm: XXX.PVT
krb5_server: xxx02.xxx.pvt
auth_provider: krb5
cache_credentials: True
id_provider: ad
ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03
krb5_store_password_if_offline: True
access_provider: simple
ldap_schema: ad
ldap_id_mappings: True
simple_allow_groups: linux@admins(a)xxx.pvt
simple_allow_users: rapid7scan(a)xxx.pvt
debug_level: 9
(Wed Jul 18 13:18:49:143281 2018) [sssd] [confdb_init_db] (0x1000): LDIF file to import:
dn: cn=config
version: 2
dn: cn=sssd,cn=config
cn: sssd
config_file_version: 2
domains: xxx.pvt
services: nss, pam
debug_level: 9
dn: cn=nss,cn=config
cn: nss
debug_level: 9
dn: cn=domain\bhcs.pvt,cn=config
cn: domain\bhcs.pvt
fallback_homedir: /home/%u
default_shell: /bin/bash
ad_domain: xxx.pvt
krb5_realm: XXX.PVT
krb5_server: xxxxxdc02.xxx.pvt
auth_provider: krb5
cache_credentials: True
id_provider: ad
ad_server: xxxxxc01, xxxxxc01, xxxxxc01, xxxxxc02, xxxxxc03
krb5_store_password_if_offline: True
access_provider: simple
ldap_schema: ad
ldap_id_mappings: True
simple_allow_groups: linux@admins(a)xxx.pvt
simple_allow_users: rapid7scan(a)xxx.pvt
debug_level: 9
(Wed Jul 18 13:18:49:143420 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143639 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143862 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:143983 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144062 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144166 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144275 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144372 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144520 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:144805 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1)
(Wed Jul 18 13:18:49:158827 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0)
(Wed Jul 18 13:18:49:159670 2018) [sssd] [add_implicit_services] (0x0040): id_provider is not set for domain [xxx.pvt], trying next domain.
(Wed Jul 18 13:18:49:159863 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [xxx.pvt]
(Wed Jul 18 13:18:49:159970 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [xxx.pvt], skipping!
(Wed Jul 18 13:18:49:160014 2018) [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error!
(Wed Jul 18 13:18:49:160068 2018) [sssd] [get_monitor_config] (0x0010): No domains configured.
(Wed Jul 18 13:18:49:160179 2018) [sssd] [main] (0x0020): Error loading configuration database: [2]: No such file or directory
Sssd.conf
[sssd]
config_file_version = 2
domains = bhcs.pvt
services = nss, pam
debug_level = 9
[nss]
debug_level = 9
[domain\xxx.pvt]
fallback_homedir = /home/%u
default_shell = /bin/bash
ad_domain = xxx.pvt
krb5_realm = xxx.PVT
krb5_server = xxxxc02.bhcs.pvt
auth_provider = krb5
cache_credentials = True
id_provider = ad
ad_server = xxxxc01, xxxxc01, xxxxdc01, xxxxdc02, xxxxc03
krb5_store_password_if_offline = True
access_provider = simple
ldap_schema = ad
ldap_id_mappings = True
# ldap_sasl_mech=GSSAPI
simple_allow_groups = linux@admins(a)xxx.pvt
simple_allow_users = rapid7scan(a)xxx.pvt
debug_level = 9
Would appreciate any assistance you could offer.
Thanks
Andrea
Andrea Laack
Host Systems
[cid:image002.jpg@01D41EA1.8969FEA0]
2401 S. 31st Street
Temple, TX 76508
Mailstop: MS-2-1.41
Office: 254-724-9490
andrea.laack(a)bswhealth.org<mailto:andrea.laack@bswhealth.org>
[cid:image003.png@01D41EA0.4137E5D0] <https://www.youracclaim.com/badges/d2b9b13f-0db9-4666-860e-146c70d45d36> [cid:image004.png@01D41EA0.4137E5D0]
**********************************************************************
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.
5 years, 9 months
groups missing when using tokengroups...
by Spike White
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.
You asked:
Can you send logs for a single lookup of "id username" with tokengroups
enabled?
Last week, I attached the logs. for one specific lookup. Even though I
severely trimmed the logs, it exceeded the max file size for this mailing
list.
It was the 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.
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
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).
5 years, 9 months
recreate machine keytab file
by Ondrej Valousek
Hi List,
Is there any way how can we recreate system keytab file of a machine joined to AD if the file has been broken/deleted?
I want to avoid doing join again as this would probably delete the existing account (with all attributes we have set).
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
5 years, 10 months
sssd id getent and secondary groups in active directory
by Ratliff, John
I'm using SSSD and realmd to join a machine to active directory.
When I run id on my user, I only get the primary group. If I run getent
group "groupname", it works...sometimes. Other times, it returns blank.
This is on a CentOS 7 machine (sssd 1.16.0)
$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)
$ getent group ssh-test-users2
ssh-test-users2:*:752629809:
$ sss_cache -E
$ getent group ssh-test-users2
ssh-test-users2:*:752629809:jdratlif
$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)
$ getent group ssh-test-users2
ssh-test-users2:*:752629809:
$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)
This was all in the span of 2 minutes.
Let me know what other information would be helpful.
Thanks.
--
John Ratliff
Research Storage / UITS / Pervasive Technology Institute
Indiana University | https://pti.iu.edu
5 years, 10 months
Why is my sssd deployment not doing cross-subdomain AD authentication?
by Spike White
sssd subject matter experts,
Why is my sssd deployment not doing cross-subdomain AD authentication?
*Background:*
I have a parent AD domain DELL.COM with trusted subdomains AMER.DELL.COM,
APAC.DELL.COM, EMEA.DELL.COM and JAPN.DELL.COM Each subdomain has a
transitive trust with DELL.COM.
So all subdomains trust each other.
I set up a first test VM deployment using sssd. I set up the cross
subdomain auth as in:
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
It worked great – allowed cross subdomain authentication. The only thing
it would not do was use tokengroups. That is, the VM was fully functional,
but I had to add ‘ldap_use_tokengroups = false’ to the sssd.conf file.
My AD experts have advised me that ‘tokengroups’ are an important AD
optimization and I should use them, if at all possible.
Using ldapsearch, I was able to verify that machine account didn’t have the
necessary privileges to query a user’s tokengroups. Thus, the fault was
mine – that this first sssd deployment couldn’t use tokengroups.
So I did another sssd deployment, using another test VM. Apparently, I did
the realm join command correct this time, as it’s able to use tokengroups.
BUT! This second test VM is not allowing cross subdomain authentication
and login. How do I fix this so that I have use of both tokengroups and
cross subdomain authentication?
(BTW -- Both test VMs are still up and operational, as described above.)
*Details:*
Here is the realm join command used in the second test VM (spikerealmd02):
kinit serviceunixinstall
realm join -v --automatic-id-mapping=no
--computer-ou='OU=Servers,OU=UNIX,DC=AMER,DC=DELL,DC=COM'
--user-principal="host/`hostname
--fqdn`(a)AMER.DELL.COM" AMER.DELL.COM
Here is the /etc/realmd.conf file from this second test VM:
[root@spikerealmd02 etc]# cat realmd.conf
[AMER.DELL.COM]
computer-ou = OU=SERVERS,OU=UNIX,DC=AMER,DC=DELL,DC=COM
automatic-id-mapping = no
manage-system = no
fully-qualified-names = no
# THIS FAILS AT DELL; serviceunixinstall apparently not allowed to create
UPNs associated with machine account.
# Set the user-prinicpal to yes to create userPrincipalName attributes for
the computer account in the realm, in the form host/computer@REALM
#user-principal = yes
[active-directory]
default_client = sssd
[service]
automatic-install = no
[users]
# shouldn't need this; should be set in AD for each UNIX-enabled user.
default-home = /home/%U
# shouldn't need this; should be set in AD for each UNIX-enabled user.
default-shell = /bin/bash
Here’s the /etc/sssd/sssd.conf file for this second test VM:
[root@spikerealmd02 sssd]# cat sssd.conf
[sssd]
debug_level = 6
domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com,
japn.dell.com
config_file_version = 2
services = nss,pam
#ldap_user_member_of = member
[pam]
pam_verbosity = 3
debug_level = 9
[nss]
debug_level = 9
filter_groups = root
filter_users = root
reconnection_retries = 3
#entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
[domain/amer.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = amer.dell.com
krb5_realm = AMER.DELL.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
#access_provider = ad
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
,dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = true
simple_allow_groups = amerlinuxsup(a)AMER.DELL.COM, amerlinuxeng(a)AMER.DELL.COM,
emealinuxsup(a)EMEA.DELL.COM, AMER.DELL.COM, emealinuxeng(a)EMEA.DELL.COM,
apaclinuxsup(a)EMEA.DELL.COM, apaclinuxeng(a)EMEA.DELL.COM
# also look at
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
[domain/apac.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = apac.dell.com
krb5_realm = APAC.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = false
simple_allow_groups = apaclinuxsup(a)APAC.DELL.COM, apaclinuxeng(a)APAC.DELL.COM
[domain/emea.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = emea.dell.com
krb5_realm = EMEA.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = true
simple_allow_groups = emealinuxsup(a)EMEA.DELL.COM, emealinuxeng(a)EMEA.DELL.COM
[domain/japn.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = japn.dell.com
krb5_realm = JAPN.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, japn.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = true
simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM
and here’s the /etc/krb5.conf file:
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
# SW mod 5/12/2018
# dns_lookup_realm = false
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = AMER.DELL.COM
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
# AMER.DELL.COM = {
# }
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
amer.dell.com = AMER.DELL.COM
.amer.dell.com = AMER.DELL.COM
*Comparing with first VM that does cross subdomain auth:*
Here’s /etc/realmd.conf of first test VM that does cross subdomain auth
(spikerealmd01):
[root@spikerealmd01 krb5.include.d]# cat /etc/realmd.conf
[AMER.DELL.COM]
computer-ou = OU=SERVERS,OU=UNIX,DC=AMER,DC=DELL,DC=COM
automatic-id-mapping = no
manage-system = no
fully-qualified-names = no
# THIS FAILS AT DELL; serviceunixinstall apparently not allowed to create
UPNs associated with machine account.
# Set the user-prinicpal to yes to create userPrincipalName attributes for
the computer account in the realm, in the form host/computer@REALM
#user-principal = yes
[active-directory]
default_client = sssd
[service]
automatic-install = no
[users]
# shouldn't need this; should be set in AD for each UNIX-enabled user.
default-home = /home/%U
# shouldn't need this; should be set in AD for each UNIX-enabled user.
default-shell = /bin/bash
Here’s /etc/sssd/sssd.conf file from same first test VM:
[root@spikerealmd01 sssd]# cat sssd.conf
[sssd]
debug_level = 6
domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com
domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com,
japn.dell.com
config_file_version = 2
services = nss, pam
#ldap_user_member_of = member
[pam]
pam_verbosity = 3
debug_level = 9
[nss]
debug_level = 9
filter_groups = root
filter_users = root
reconnection_retries = 3
#entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
[domain/amer.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = amer.dell.com
krb5_realm = AMER.DELL.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.dell.com
#ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM
ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = false
simple_allow_groups = amerlinuxsup(a)AMER.DELL.COM, amerlinuxeng(a)AMER.DELL.COM
# also look at
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
[domain/apac.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = apac.dell.com
krb5_realm = APAC.DELL.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.dell.com
#ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM
ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = false
simple_allow_groups = apaclinuxsup(a)APAC.DELL.COM, apaclinuxeng(a)APAC.DELL.COM
[domain/emea.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = emea.dell.com
krb5_realm = EMEA.DELL.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.dell.com
#ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM
ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = false
simple_allow_groups = emealinuxsup(a)EMEA.DELL.COM, emealinuxeng(a)EMEA.DELL.COM
[domain/japn.dell.com]
debug_level = 9
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = japn.dell.com
krb5_realm = JAPN.DELL.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.dell.com
#ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM
ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM
ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
ldap_use_tokengroups = false
simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM,
linux-core-engineering, amer.dell.com
Here’s /etc/krb5.conf file:
[root@spikerealmd01 etc]# cat krb5.conf
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
# SW mod 5/12/2018
# dns_lookup_realm = false
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = AMER.DELL.COM
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
# AMER.DELL.COM = {
# }
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
amer.dell.com = AMER.DELL.COM
.amer.dell.com = AMER.DELL.COM
[root@spikerealmd01 etc]#
*Other details:*
If I query group membership of an engineer in APAC:
id admjesse_chan
on the good VM (spikerealmd01) I see all expected groups and I see this in
the /var/log/sssd/sssd_apac.dell.com.log file:
…
(Sun Jul 1 15:14:30 2018) [sssd[be[apac.dell.com]]]
[sdap_initgr_rfc2307bis_next_base] (0x0400): Searching for parent groups
for user [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] with base
[DC=apac,DC=dell,DC=com]
(Sun Jul 1 15:14:30 2018) [sssd[be[apac.dell.com]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(member=CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com)(objectClass=group)(sAMAccountName=*))][DC=apac,DC=dell,DC=com].
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]]
[sdap_initgr_rfc2307bis_process] (0x1000): Found 4 parent groups for user [
AdmJesse_Chan(a)apac.dell.com]
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]]
[sysdb_get_direct_parents] (0x2000): searching sysdb with filter
[(&(objectCategory=group)(member=name=AdmJesse_Chan(a)apac.dell.com
,cn=users,cn=apac.dell.com,cn=sysdb))]
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]]
[sysdb_get_direct_parents] (0x1000): AdmJesse_Chan(a)apac.dell.com is a
member of 4 sysdb groups
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]]
[save_rfc2307bis_user_memberships] (0x2000): Updating memberships for
AdmJesse_Chan(a)apac.dell.com
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [sysdb_set_entry_attr]
(0x0200): Entry
[name=AdmJesse_Chan(a)apac.dell.com,cn=users,cn=apac.dell.com,cn=sysdb]
has set [ts_cache] attrs.
(Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]]
[dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:3::apac.dell.com:
name=admjesse_chan(a)apac.dell.com] from reply table
(Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]]
[sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN
[CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com], will use
associated map
(Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]] [sdap_parse_entry]
(0x1000): OriginalDN:
[CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com].
(Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]]
[sdap_asq_search_parse_entry] (0x2000): DN
[CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] did not match the
objectClass [group]
(Sun Jul 1 15:14:36 2018) [sssd[be[apac.dell.com]]]
[sdap_nested_group_hash_insert] (0x4000): Inserting
[CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] into hash table
[users]
(Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]]
[sdap_get_primary_name] (0x0400): Processing object AdmJesse_Chan
(Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]]
[sysdb_cache_search_users] (0x2000): Search users with filter:
(&(objectCategory=user)(originalDN=CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com))
(Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]]
[sdap_find_entry_by_origDN] (0x4000): Searching cache for
[CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com].
(Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]]
[sdap_fill_memberships] (0x1000): member #2019 (CN=AdmJesse_Cha
,OU=ADMAccounts,DC=apac,DC=dell,DC=com): [name=AdmJesse_Chan(a)apac.dell.com
,cn=users,cn=apac.dell.com,cn=sysdb]
If I do the same query on the bad VM (spikerealmd02):
[root@spikerealmd02 sssd]# id admjesse_chan
id: admjesse_chan: no such user
and I see nothing in the sssd_apac.dell.com.log file:
[root@spikerealmd02 sssd]# grep -i admjesse_chan sssd_apac.dell.com.log
[root@spikerealmd02 sssd]#
Please help,
Spike
5 years, 10 months
Nested group lookups
by Tom
Hey All,
If I want sssd to lookup if I belong in any groups or nested groups based on a string ( wildcard) in a group, what be my best options?
I would like to keep the ad_access_filter to a minimum and grant access if a user is part of a subgroup.
If user is in B and B is in A, allow access as long as A appears on the filter list for example.
Cheers,
Tom
Sent from my iPhone
5 years, 10 months
Behaviour of refresh_expired_interval
by John Hearns
I have an AD setup where users can be a member of perhaps 130 groups.
When I run 'groups jbloggs' this can take 90 seconds or even longer.
I have reduced that time to perhaps 20 seconds by setting
ignore_group_members = TRUE
Once the information is cached the groups command returns in less that one
second.
However, after a length of time the cache seems to be invalidated and the
information is fetched again from the server, taking 20 seconds again.
The cacheing parameters are set to:
entry_cache_timeout = 5400
entry_cache_user_timeout = 5400
entry_cache_group_timeout = 5400
refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group information is
refreshed in the background.
So a user running the groups command would always see freshly cached values?
Clearly I am not understanding something here.
5 years, 10 months