Enumerate users from external group from AD trust
by Bolke de Bruin
Hello,
I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain.
One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using
“getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to
add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
[root@master centos]# id bolke(a)ad.local
UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test(a)ad.local)
[root@master centos]# getent group ad_users
ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local>
If I clear the cache (sss_cache -E) the entry is gone again:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
My question is how do I get sssd to enumerate *all users* in a group consistently?
Thanks!
Bolke
* https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-g...
10 months
Group disappears from users / no group name gets resolved
by Jamal Mahmoud
We've been experiencing an intermittent issue relating to SSSD v1.15.2, we are running CentOS7.4 on our workstations. We use SSSD to communicate with our Active Directory to pull users for auth. The majority of users have a certain group set as their primary group and some departments have it as an additional group. Most of the time this group works fine on all workstations but sometimes we will run into an issue where a user can no longer access the privileges attained from the group. For users who have it set as primary, the id command returns a gid without the name and for users who have it as an additional group, it doesn't appear at all. I've managed to capture output from sssd services and there are a few interesting lines that I thought I should share with you as I don't understand what they mean. I should add that when this error occurs, restarting the sssd.service usually works, if not, sss_cache -E works, and if that doesn't work, removing the workstation from the realm, de
leting the sssd db and rejoining seems to be the final trick that works.
Regarding the logs, the symptoms I noted are below:
1. getent group *mygroup* returns nothing
2. id user returns a gid without a resolved group name (if it is a primary group)
3. I had to leave the realm, delete the db and rejoin to get sssd to work properly again.
in sssd_nss.log i found this entry:
(Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for group(a)domain.com[0]! Skipping
and in the sssd_domain.com.log:
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged accounts,DC=domain,DC=com] is unknown object
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x0400): More members were missing than the deref threshold
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Dereferencing members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] (0x2000): Server supports ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] using ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] (0x2000): Searching XXX.XXX.XXX.XXX:389
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] (0x0400): WARNING: Disabling paging because scope is set to base.
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com].
I've redacted the entries but I'm sure you can get the jist of whats happening here hopefully. If there is anything else you need, please do not hesitate to ask! If these logs don't point to anything could you maybe provide some advice on what to look for when parsing?
Thanks,
Jamal
10 months, 1 week
SSSD strangeness
by simonc99＠hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
10 months, 3 weeks
AD user is granted access when it should be denied
by Emil Petersson
Hi,
I am running sssd-1.16.4-21.el7.x86_64 (from CR repo) on a CentOS 7 client. I authenticate to AD 2016, and control access to servers using GPO. For some reason, a completely unprivileged user in AD is allowed to login, and I'd like to understand why.
Here's a sanitized sssd.conf:
[sssd]
domains = prd.domain.com
config_file_version = 2
services = nss, pam, sudo
full_name_format = %1$s
default_domain_suffix = prd.domain.com
[domain/prd.domain.com]
debug_level = 9
ad_domain = prd.domain.com
ad_site = XX1
ad_server = dc000.prd.domain.com, dc001.prd.domain.com
krb5_realm = PRD.DOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = true
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = ad
ldap_sudo_search_base = DC=domain,DC=com
entry_cache_sudo_timeout = 10
enumerate = true
dyndns_update = false
ad_gpo_access_control = enforcing
ldap_idmap_default_domain_sid = S-1-5-21-6607581186-1994368826-2594857426
ldap_idmap_default_domain = prd.domain.com
ad_gpo_implicit_deny = true
auto_private_groups = true
ad_gpo_ignore_unreadable = true
When I try to SSH to the client using my unprivileged user, I am getting the following output from the SSSD debug:
[sysdb_gpo_get_gpo_result_setting] (0x0400): key [SeDenyRemoteInteractiveLogonRight] value [*S-1-5-32-546]
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 1
[ad_gpo_access_check] (0x0400): denied_sids[0] = S-1-5-32-546
... snip ...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-6607581186-1994368826-2594857426-2570
[ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-6607581186-1994368826-2594857426-513
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
I'm trying to understand why this user is being granted access. I find it especially confusing as there is clearly one deny sid and no allow sids detected. The wanted behaviour is that the user should be denied access as long as I've not explicitly allowed it in AD.
Thanks!
11 months, 2 weeks
Question concerning SSH key attributes
by Lawrence Kearney
A question concerning the following SSSD directives:
ldap_user_ssh_public_key =
ldap_host_ssh_public_key =
Both default to "sshPublicKey" values, but other than the obvious stated
use cases (in the directive names and man file entries) I feel I'm missing
something concerning the " ldap_host_ssh_public_key" directive.
For example, using the default configuration, the SSSD pulls down the
public key(s) stored for a user stored in the " sshPublicKey" attribute
using the "/usr/bin/sss_ssh_authorizedkeys" utility. to facilitate access
to a predetermined set of hosts.
What is the use case for the " ldap_host_ssh_public_key" directive? Is it
somehow used to store the public Key for a particular host (and why?) and
does it have any relationship to the "/usr/bin/sss_ssh_knownhostsproxy"
utility used to centralise (and distribute?) host keys?
Any info would be most useful and as always, thank you!
-- lawrence
--
Lawrence Kearney
12 months
Allow me to introduce my situation….
by Spike White
All,
In recent postings, there’s been some (quite correct!) inferences about my
situation. Let me dispel any confusion, so you’re aware of my perspective.
I work for a Fortune 500 company in their IT department. Our company and
team has done Linux and UNIX AD integration using 2 ½ commercial products
for over 12 years now. (that third product was used only in a very limited
scope).
Our team has oversight for about 30,000 Linux servers – 17K of them that
are AD-integrated and 13K in the process of getting there.
So, my team and our server support organization has a wealth of experience
with the Linux client configurations of AD integration. We know our
company incident procedures and that escalation process. Thus, I can say
with confidence (for instance) that Linux sysadmins are engaged in the
infrequent occurrence that AD integration is bulloxed on a particular Linux
server.
So, while we have a wealth of experience in AD/LDAP Linux and app
integration, we are frankly newbies to sssd. I fully admit to my
inexperience in sssd configuration and setup. However, I have been using
it and evaluating it for almost a year. I have it working on RHEL7, RHEL8
and (just last week) RHEL6.
I have gone through all anticipated test cases and – except for one totally
obscure edge case -- sssd appears like it can do everything the commercial
AD integration products can do. I say that – although I have two open sssd
cases with our OS vendor.
1. One has been discussed already on this forum – “realm permit”
segfaulting (but only on RHEL8). Our OS vendor has provided a work-around
for this.
2. I believe the second bug is not a “bug” at all – but it’s due to
my lack of understanding of AD and my inexperience with sssd. I’m
currently working that with our OS vendor as well.
Incidentally, if it appears that I’m singularly focused on AD – that’s
because I am. That’s all my company uses for its back-end authentication
mechanism. I’m also singularly focused on RHEL and RHEL-derived Linux
servers, for similar reasons.
Thus, when I suggest an RFE, I’m speaking from my perspective only and my
company’s Linux perspective. I fully realize that other companies have
different escalation policies, different authentication back-ends and
different situations. I fully realize that any RFE I suggest would be
half-baked (at best) – if accepted, it would surely be re-written to be
more generic and useful for a larger target audience.
Spike
12 months
Offline caching of group names and memberships?
by Spike White
All,
Our cybersecurity team doesn’t allow Linux sysadmins to directly log in as
root. (violates accountability, auditability and traceability). We log in
with an ADM account, which is then eligible to become root via ‘sudo su –‘.
That is, all members of a particular group are allowed to sudo to root.
This is preferred because with modern sudo versions all sudo sessions are
session-logged.
Anyway, if I log in with my ADM account and someone shuts down sssd, it no
longer knows what groups I’m in. That is, the session is still there – but
it cannot look up the group names.
[admspike_white@zzzdmsdev06 ~]$ id
uid=2025431 gid=1002 groups=1002,2284295
Because the sudo privs are based on group name, it doesn’t allow Linux
sysadmins to become root and thus start sssd.
Is there a way to cache those group names and memberships? Say with nscd?
So that if sssd is (temporarily) shut down, we can become root and start up?
Obviously, we can go look up the root password for the particular server –
but that’s a painful portal. It’d be better if we could cache group names
and memberships, if sssd is temporarily down or offline.
(We have other AD integration products that have this “offline caching”
feature that can enabled or disabled.)
Spike
12 months
autofs with samba AD
by wipe＠mailbox.org
Hello list,
I'm trying to setup sssd to access automounter rules stored on an AD (samba 4.7.6).
I followed the instructions on this site, however it doesn't work for me.
https://ovalousek.wordpress.com/2015/08/03/autofs/
In the sssd_logfile I see, that the "auto.master" map is found by sssd within the ldap search path.
However, the reference to the auto.home and the corresponding user mounts does not seem to be found.
Using sssd to authenticate against Active Directory works well.
Any ideas what's going wrong here? Thanks for looking in this issue!
OS: Ubuntu 18.04.3 LTS
sssd 1.16.1-1ubuntu1.4
sssd-ad 1.16.1-1ubuntu1.4
sssd-ad-common 1.16.1-1ubuntu1.4
sssd-common 1.16.1-1ubuntu1.4
sssd-dbus 1.16.1-1ubuntu1.4
sssd-ipa 1.16.1-1ubuntu1.4
sssd-krb5 1.16.1-1ubuntu1.4
sssd-krb5-common 1.16.1-1ubuntu1.4
sssd-ldap 1.16.1-1ubuntu1.4
sssd-proxy 1.16.1-1ubuntu1.4
sssd-tools 1.16.1-1ubuntu1.4
Here is the configuration. Additionally, I attached logfiles with log_level 9
****sssd.conf****
[sssd]
domains = info.privat
config_file_version = 2
services = nss, pam, autofs
[pam]
[nss]
[autofs]
[domain/info.privat]
debug_level = 5
ad_server = tfaddc2.info.privat
access_provider = ad
auth_provider = ad
krb5_realm = INFO.PRIVAT
cache_credentials = True
id_provider = ad
autofs_provider = ad
ldap_autofs_entry_key = cn
ldap_autofs_entry_object_class = nisObject
ldap_autofs_entry_value = nisMapEntry
ldap_autofs_map_name = nisMapName
ldap_autofs_map_object_class = nisMap
ldap_autofs_search_base = ou=automount,dc=info,dc=privat
nsswitch.conf
automount: files sss
****AD****
dn: OU=automount,DC=info,DC=privat
objectClass: top
objectClass: organizationalUnit
ou: automount
name: automount
dn: CN=auto.master,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisMap
cn: auto.master
name: auto.master
objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.master
dn: CN=auto.home,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisMap
cn: auto.home
name: auto.home
objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.home
dn: CN=/home/,CN=auto.master,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisObject
objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.master
cn: /home/
name: /home/
nisMapEntry: auto.home
dn: CN=user1,CN=auto.home,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisObject
objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.home
nisMapEntry: -fstype=nfsv4,nosuid,rw,dir_index,user_xattr,proto=tcp,port=2049 server:/export/lra/user/user1
cn: user1
name: user1
12 months
How do new LDAP security recommendations from MS affect sssd clients?
by Spike White
All,
Microsoft has announced a new vulnerability in its AD domain controllers.
They are promising a fix by mid-Jan 2020, but in the meantime
they have offered LDAP hardening recommendations so that these controllers
are not vulnerable.
Those recommendations are:
- enable LDAP channel binding and
- LDAP signing on Active Directory Domain Controllers.
(I don't pretend to know what that is.)
My question is -- if our AD admins implement these recommended hardenings,
what impact will that have on our sssd clients?
Spike
12 months
sssd_be core dumping when ‘realm permit’ command run under puppet control…
by Spike White
All,
This is a strange one. When we exec this command under puppet control:
/usr/sbin/realm permit -R AMER.COMPANY.COM
processehcprofiler(a)AMER.COMPANY.COM
Then sssd_be core dumps (segfault).
When we run that ‘realm permit’ command natively on the command line, it
executes flawlessly. No core dump.
Naturally, our first thought was that it’s something different in the
environment. So we dumped the environment under which puppet exec resource
runs.
Yes, quite minimal.
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36:
LD_LIBRARY_PATH=
LANG=en_US.UTF-8
HISTCONTROL=ignoredups
HOSTNAME=austgcore25.us.company.com
S_COLORS=auto
PWD=/root
APT_LISTCHANGES_FRONTEND=none
DEBIAN_FRONTEND=noninteractive
APT_LISTBUGS_FRONTEND=none
MAIL=/var/spool/mail/root
SHELL=/bin/bash
TERM=xterm
SHLVL=2
MANPATH=:/opt/puppetlabs/puppet/share/man
PATH=/bin:/usr/bin:/sbin:/usr/sbin
HISTSIZE=1000
LESSOPEN=||/usr/bin/lesspipe.sh %s
_=/bin/env
But when we create a bash session with no environment, then add this
puppet-supplied environment and run the above realm permit– all is still
well.
We can reproduce this easily in puppet. Just delete our breadcrumb file
(so that puppet re-executes this ‘realm permit’ command). And execute
another puppet agent run.
Doing this, we obtained a core dump from sssd_be. And it points to some
code in ad_id.c:
[root@austgcore25 tmp]# gdb -c
core-sssd_be.15405.austgcore25.us.company.com.1563210863
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-5.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 15405]
Reading symbols from /usr/libexec/sssd/sssd_be...Reading symbols from
/usr/lib/debug/usr/libexec/sssd/sssd_be-2.0.0-43.el8.x86_64.debug...done.
done.
warning: Ignoring non-absolute filename: <linux-vdso.so.1>
Missing separate debuginfo for linux-vdso.so.1
Try: dnf --enablerepo='*debug*' install
/usr/lib/debug/.build-id/06/44254f9cbaa826db070a796046026adba58266
warning: .dynamic section for "/usr/lib64/libndr-nbt.so.0.0.1" is not at
the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/libexec/sssd/sssd_be --domain AMER.COMPANY.COM
--uid 0 --gid 0 --logger=files'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f79444f53c0 in ad_get_account_domain_search
(req=req@entry=0x5557b6fd45b0)
at src/providers/ad/ad_id.c:1276
1276 state->filter = sdap_combine_filters(state, state->base_filter,
(gdb)
This is in RHEL8.
What we suspect is that the shell in which puppet executes this ‘realm
permit’ is not supplying something that this executable needs. If we know
what it is, we can preface our puppet exec resource code snippet with the
missing piece.
Spike
PS This ‘realm permit’ does seem to perform the correct actions
eventually. It adds the expected user to the simple_allow_users line of
the appropriate AD domain in /etc/sssd/sssd.conf file. But because it
segfaults and then has to start up again, it takes a very long time to
complete the puppet run. (There’s about 20 – 30 users + groups allowed; it
has to segfault on each of them).
1 year
