ldap_use_tokengroups=False is not returning correct results
by Sanjay Agrawal
We are noticing that with ldap_use_tokengroups=False is not returning same results as with tokengroups. We think, it is due to two issues show below. Can you please confirm if they are a known issues.
Thanks,
Issue 1: It is not checking nested membership of gidNumber group, so missing group "group1498" from the list
$ ldapsearch -Q -h ad_server -LLL -b 'CN=user3901,OU=Service Accounts,DC=mydomain,DC=com' -s base 'objectclass=*' | grep -E "primaryGroupID|gidNumber|memberOf"
memberOf: CN=group548,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1414,OU=Groups,DC=mydomain,DC=com
primaryGroupID: 513
gidNumber: 32771
$ ldapsearch -Q -h ad_server -LLL -b 'OU=Groups,DC=mydomain,DC=com' '(msSFU30Name=group1191)' | grep -E "gidNumber|memberOf"
memberOf: CN=group1498,CN=Builtin,DC=mydomain,DC=com
gidNumber: 32771
testhost4:0# tail -1 /etc/sssd/sssd.conf
ldap_use_tokengroups = False
testhost4:0# groups user3901
user3901 : group1191 group548 group1414
Issue 2: without tokengroups, It's not considering primaryGroupID as group of the user, so this is missing from group list
All tokengroups for this user
$ ldapsearch -Q -h ad_server -LLL -b 'CN=user5305,CN=Users,DC=mydomain,DC=com' -s base 'objectclass=*' tokenGroups
dn: CN=user5305,CN=Users,DC=mydomain,DC=com
tokenGroups:: AQIAAAAAAAUgAAAAIQIAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9gBwCAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I95d4AAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9FwQBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9YB0BAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I91uIAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9kQQAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9vBwCAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9594AAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9gHABAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9KAYBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9C4gBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9xgQBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9fOIAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9K14AAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I97BwBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I98j4BAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9sQUBAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9Zt8AAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9s7sAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I95aoAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9tOIAAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I98M4AAA==
tokenGroups:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9AQIAAA==
All memberof/PrimaryGid and gidNumber for the user
ldapsearch -Q -h ad_server -LLL -b 'DC=mydomain,DC=com' '(ldap_group=user5305)' | egrep "name|gidNumber|memberOf|primary|AccountName"
memberOf: CN=group136,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group404,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group938,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group717,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group655,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group714,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1015,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group715,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group945,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group863,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1243,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group721,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group588,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group869,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1110,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group934,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1099,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group669,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1520,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group768,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group1375,OU=Groups,DC=mydomain,DC=com
memberOf: CN=group226,OU=Groups,DC=mydomain,DC=com
name: user5305
primaryGroupID: 513
sAMAccountName: user5305
gidNumber: 33040
check group with objectSid AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9AQIAAA==
$ ldapsearch -Q -h ad_server -LLL -b 'DC=mydomain,DC=com' '(ldap_group=group1191)' objectSid name
dn: CN=Domain Users,OU=Groups,DC=mydomain,DC=com
name: Domain Users
objectSid:: AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9AQIAAA==
ldap_group: group1191
base64 of this objectSid AQUAAAAAAAUVAAAADk/CBIowfwb4F/I9AQIAAA==
S-1-5-21-79843086-108998794-1039276024-513
- this is the primaryGroupID, which is missing from group list
From box using tokenGroup=False, see group1191 (primaryGroupID) is missing from the group list
testhost4:130# tail -1 /etc/sssd/sssd.conf
ldap_use_tokengroups = False
testhost4:0# groups user5305
user5305 : group1520 group226 group1375 group768 group136 group1243 group669 group1099 group934 group1110 group869 group588 group721 group863 group945 group715 group1015 group714 group655 group717 group938 group404
Sanjay Agrawal
3 years, 2 months
SSSD InfoPipe responder cache and attributes
by Lawrence Kearney
SSSD team,
Hello! I'm a bit perplexed on how to validate and test data read by the
Dbus/IFP responder. I'd like to better understand the cache aspects and how
to validate that non-default whitelisted attributes are in fact exposed.
I'm using the AD provider against a 2012 R2 back end.
[sssd]
config_file_version = 2
services = nss,pam,pac,ifp
domains = dvc.darkvixen.com
[nss]
reconnection_retries = 3
filter_users = root,bin,daemon,games,gdm,lp,nobody,openslp,rpc,statd
filter_groups = root,bin,daemon,sys,disk,lp,audio,floppy,cdrom,video,games
[pam]
[pac]
[ifp]
allowed_uids = root,wwwrun,sssd
user_attributes = +mail,+department,+telephoneNumber,-gecos
[domain/dvc.darkvixen.com]
id_provider = ad
enumerate = false
cache_credentials = true
case_sensitive = false
override_homedir = /home/%u
override_shell = /bin/bash
override_gid = 1727401607
ldap_user_extra_attrs = mail,department,telephoneNumber
Output from sssctl:
# sssctl user-show msteele
Name: msteele
Cache entry creation date: 01/08/21 10:14:35
Cache entry last update time: 01/08/21 14:04:18
Cache entry expiration time: 01/08/21 15:34:18
Initgroups expiration time: 01/08/21 15:34:18
Cached in InfoPipe: No
# sssctl user-checks msteele
user: msteele
action: acct
service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401607
- gecos: Ming Steele
- home directory: /home/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos:
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
Should the attributes in fact be cached and displayed?
Packages installed:
# rpm -qa | grep sss
python-sssdconfig-1.16.5-10.el7_9.5.noarch
sssd-client-1.16.5-10.el7_9.5.armv7hl
libsss_autofs-1.16.5-10.el7_9.5.armv7hl
sssd-common-1.16.5-10.el7_9.5.armv7hl
libsss_simpleifp-1.16.5-10.el7_9.5.armv7hl
sssd-ad-1.16.5-10.el7_9.5.armv7hl
libsss_idmap-1.16.5-10.el7_9.5.armv7hl
libsss_certmap-1.16.5-10.el7_9.5.armv7hl
sssd-libwbclient-1.16.5-10.el7_9.5.armv7hl
libsss_sudo-1.16.5-10.el7_9.5.armv7hl
sssd-polkit-rules-1.16.5-10.el7_9.5.armv7hl
sssd-dbus-1.16.5-10.el7_9.5.armv7hl
sssd-common-pac-1.16.5-10.el7_9.5.armv7hl
sssd-tools-1.16.5-10.el7_9.5.armv7hl
sssd-ldap-1.16.5-10.el7_9.5.armv7hl
libsss_nss_idmap-1.16.5-10.el7_9.5.armv7hl
sssd-krb5-common-1.16.5-10.el7_9.5.armv7hl
python-sss-1.16.5-10.el7_9.5.armv7hl
sssd-krb5-1.16.5-10.el7_9.5.armv7hl
-- lawrence
3 years, 3 months
Failed to change user login shell via chsh on SSSD client connected to 389ds
by SJTU
Hi,
We host a 389ds LDAP service and connect it via SSSD. All servers and clients are on CentOS 7. ldapmodify and passwd work well. But we fail to change user login shell via chsh. For example,
$ chsh -s /bin/bash
Changing shell for hpc-jianwen.
Password:
chsh: user "hpc-jianwen" does not exist.
$ id hpc-jianwen
uid=1513(hpc-jianwen) gid=1514(hpc-jianwen) groups=1514(hpc-jianwen)
Any suggestion is welcome.
Thank you!
Jianwen
3 years, 3 months
fast tunnel and authentication indicator
by Abdelkader Chelouah
Hello,
I configured MIT Krb5-1.18.3 KDC to use FAST OTP with authentication
indicator "*strong*".
$ cat kdc.conf
...
[otp]
softid = {
server = 192.168.0.68:1812
secret = /etc/.radius.secret
strip_realm = true
indicator = strong
#timeout = <integer> (default: 5 [seconds])
#retries = <integer> (default: 3)
}
The kerberos Realm "DNS.PODMAN" has only two "otp" principals, *alice*
and *bob.*
$ kadmin.local getstrs alice
otp: [{"type":"softid"}]
$ kadmin.local getstrs bob
otp: [{"type":"softid"}
Alice's password was purged with the command
kadmin.local purgekeys -all alice
On the sssd host (RHEL 7.9), sssd service uses the following
configuration file
[sssd]
domains = DNS.PODMAN
services = nss,pam,ssh
config_file_version = 2
debug_level = 9
[nss]
filter_users = root
filter_groups = root
reconnection_retries = 3
entry_cache_nowait_percentage = 75
debug_level = 9
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
[domain/DNS.PODMAN]
debug_level = 0x04000
id_provider = ldap
ldap_uri = ldaps://kerb.dns.podman:636/
ldap_search_base = dc=dns,dc=podman
ldap_schema = rfc2307bis
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca.crt
ldap_sasl_mech = gssapi
ldap_sasl_authid = sssd/sssd.dns.podman
ldap_krb5_keytab = /etc/sssd/sssd.keytab
ldap_krb5_init_creds = true
ldap_krb5_ticket_lifetime = 86400
ldap_user_search_base = ou=people,dc=dns,dc=podman
ldap_user_object_class = posixAccount
ldap_group_search_base = ou=groups,dc=dns,dc=podman
ldap_group_object_class = groupOfNames
ldap_group_gid_number = gidNumber
ldap_group_member = member
auth_provider = krb5
krb5_server = kerb.dns.podman
krb5_realm = DNS.PODMAN
cache_credentials = true
krb5_keytab = /etc/krb5.keytab
krb5_use_fast = try
krb5_fast_principal = host/sssd.dns.podman
min_id = 10000
max_id = 20000
#enumerate = False
enumerate = True
[ssh]
debug_level = 9
# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
2 host/sssd.dns.podman(a)DNS.PODMAN
2 host/sssd.dns.podman(a)DNS.PODMAN
2 host/sssd.dns.podman(a)DNS.PODMAN
2 host/sssd.dns.podman(a)DNS.PODMAN
2 host/sssd.dns.podman(a)DNS.PODMAN
2 host/sssd.dns.podman(a)DNS.PODMAN
The service principal host/sssd.dns.podman is configured to require the
"strong" authentication indicator value.
$ kadmin getstrs host/sssd.dns.podman
require_auth: strong
When ssh to the sssd host with *alice* account, authentication using otp
is working fine
[root@client /]# ssh alice@sssd
alice@sssd's password: <otp value>
Last login: Sat Dec 19 19:06:36 2020 from client.dns.podman
[alice@sssd ~]
However, if I ssh to the sssd host with *bob* account, I can login with
bob's password even if the service principal host/sssd.dns.podman is
configured to require the "strong" authentication indicator value
[root@client /]# ssh bob@sssd
bob@sssd's password: <bob's password>
Last login: Mon Dec 21 19:05:03 2020 from client.dns.podman
[bob@sssd ~]$
1. Why password authentication for bob principal succeeded while
authentication indicator is "strong" ?
2. Is it possible to configure sssd to enforce "otp" authentication ?
3 years, 3 months
select sssd method for authentication
by mbalembo
Hello,
I would like to configure pam_sss.so as to separate authentication methods ;
in my case i use both password and smartcard.
My problem is that when a smartcard is inserted, you can't use password
anymore because
it will prompt for the PIN and fail without fallback.
Ideally i'd like to configure pam/sssd/sddm to try the "password" as a
password, then try as a PIN for inserted smartcards.
Can i configure sssd to do that ?
My understanding in that even if you set pam_sss to/try_cert_auth/, it will
not fallback to password if a smartcard is inserted.
Thanks for your help,
Marc
3 years, 3 months
CVE-2020-1472 vulnerablity for samba-client-libs RPM on RHEL7...
by Spike White
sssd experts,
On ~Dec 14th, CVE-2020-1472 was reported against RHEL7. It's a samba
vulnerability. Among the very many vulnerable RPMs identified in the
errata, they list samba-client-libs RPM.
The sssd-ad RPM has an RPM dependency on this samba-client-libs RPM. I
believe the sssd-ad RPM is the RPM that provides the sssd backend to
integrate with AD. Thus, if we remove sssd-ad RPM, I believe we'll break
our current direct AD integration with sssd.
I'm trying to gauge our exposure. As documented exploits using this CVE
are allegedly being seen in the wild, MITRE is rating this CVE as a 100.
But I question that -- for our environment.
We directly integrate our RHEL7 and 8 clients to AD. Our AD DCs are true
Windows domain controllers.
As I understand it, our exposure should be minimal or none because:
1. This CVE is mainly for if you run a Samba server as an AD DC (we do
not), and
2. Since we directly integrate to AD from our sssd clients, I'm not sure
that any code in this
samba-client-libs RPM ever gets exercised.
Comments?
I realize this CVE will be remediated in our next Linux patch cycle
(~mid-Jan). But I'm not sure all companies are as pro-active.
Spike
3 years, 3 months
Re: Failed to change user login shell via chsh on SSSD client connected to 389ds
by SJTU
Hi, Alexey
The chsh comes with CentOS 7 has been linked with libuser.
Thank you!
Jianwen
[root@login1 ~]# ldd `which chsh`
linux-vdso.so.1 => (0x00007ffcd5e4d000)
libuser.so.1 => /lib64/libuser.so.1 (0x00002b8203cf3000)
libpam.so.0 => /lib64/libpam.so.0 (0x00002b8203f12000)
libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00002b8204121000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b8204325000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b820454c000)
libc.so.6 => /lib64/libc.so.6 (0x00002b8204768000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00002b8204b36000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002b8204d3a000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002b8204f8b000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b82052a1000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00002b82054d8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b8205701000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00002b8205905000)
/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux.so.2 (0x00002b82038c9000)
libffi.so.6 => /lib64/libffi.so.6 (0x00002b8205b67000)
libfreebl3.so => /lib64/libfreebl3.so (0x00002b8205d6f000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00002b8205f72000)
3 years, 3 months
sssd taking long time to resolve some queries
by Sanjay Agrawal
We are noticing that sometimes sssd take very long to resolve some queries. They are happens when sssd_be is 100% during that interval. SO with debug_level 9 I tried to capture but I am see that no log update in sssd_be. Following is sample output from sssd_be log during this time interval. SO it is stuck in save_group ? The group in question here is very large group.
(2020-12-21 13:33:37:929203): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 13:33:38:018075): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 13:33:38:018253): [be[mydomain]] [sdap_save_groups] (0x4000): Group 4 members processed!
--
(2020-12-21 14:18:13:015516): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [orig_member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 14:18:13:040536): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 14:18:13:040796): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 processed!
--
(2020-12-21 14:18:13:102591): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 14:18:18:782683): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 14:18:18:783006): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 members processed!
--
(2020-12-21 14:23:13:013189): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [orig_member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 14:23:13:037017): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 14:23:13:037266): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 processed!
--
(2020-12-21 14:23:13:098968): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 14:23:13:765062): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 14:23:13:765277): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 members processed!
--
(2020-12-21 15:16:01:151526): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 15:16:07:549879): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 15:16:07:550229): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 members processed!
--
(2020-12-21 16:06:04:098209): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 16:06:09:528503): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 16:06:09:528813): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 members processed!
--
(2020-12-21 16:38:13:017447): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [orig_member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 16:38:13:043604): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 16:38:13:043817): [be[mydomain]] [sdap_save_groups] (0x4000): Group 2 processed!
--
(2020-12-21 16:38:13:133200): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 16:38:16:725696): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 16:38:16:726140): [be[mydomain]] [sdap_save_groups] (0x4000): Group 2 members processed!
--
(2020-12-21 17:26:22:880163): [be[mydomain]] [sysdb_ldb_msg_difference] (0x2000): Replaced/extended attr [member] of entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb]
(2020-12-21 17:26:29:093140): [be[mydomain]] [sysdb_set_entry_attr] (0x0200): Entry [name=group1187@mydomain,cn=groups,cn=mydomain,cn=sysdb] has set [cache, ts_cache] attrs.
(2020-12-21 17:26:29:093619): [be[mydomain]] [sdap_save_groups] (0x4000): Group 0 members processed!
Any help is really appreciated.
Thanks,Sanjay Agrawal
3 years, 3 months
Authentication failing
by Orion Poplawski
My laptop has gotten itself into a bad state and won't let me log in:
(2020-12-29 12:32:37): [pam] [sss_cmd_get_version] (0x0200): Received client
version [3].
(2020-12-29 12:32:37): [pam] [sss_cmd_get_version] (0x0200): Offered version [3].
(2020-12-29 12:32:37): [pam] [pam_cmd_acct_mgmt] (0x0100): entering
pam_cmd_acct_mgmt
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): name
'orion' matched without domain, user is orion
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): using
default domain [ad.nwra.com]
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): domain: ad.nwra.com
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): user: orion
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): service: sshd
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): tty: ssh
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): ruser: not set
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): rhost: 10.10.20.7
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): authtok type: 0
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): newauthtok type: 0
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): priv: 1
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): cli_pid: 194899
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): logon name: orion
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): flags: 0
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): name
'orion' matched without domain, user is orion
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): using
default domain [ad.nwra.com]
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): name
'orion' matched without domain, user is orion
(2020-12-29 12:32:37): [pam] [sss_parse_name_for_domains] (0x0200): using
default domain [ad.nwra.com]
(2020-12-29 12:32:37): [pam] [cache_req_common_process_dp_reply] (0x0040): CR
#256: Could not get account info [1432158212]: SSSD is offline
(2020-12-29 12:32:37): [pam] [pam_dp_send_req] (0x0100): Sending request with
the following data:
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): domain: ad.nwra.com
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): user: orion(a)ad.nwra.com
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): service: sshd
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): tty: ssh
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): ruser: not set
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): rhost: 10.10.20.7
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): authtok type: 0
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): newauthtok type: 0
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): priv: 1
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): cli_pid: 194899
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): logon name: orion
(2020-12-29 12:32:37): [pam] [pam_print_data] (0x0100): flags: 0
(2020-12-29 12:32:37): [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req
returned 0
(2020-12-29 12:32:37): [pam] [pam_dp_send_req_done] (0x0020): PAM handler
failed [1432158212]: SSSD is offline
(2020-12-29 12:32:37): [pam] [filter_responses] (0x0100):
[pam_response_filter] not available, not fatal.
(2020-12-29 12:32:37): [pam] [pam_reply] (0x0200): blen: 28
(2020-12-29 12:32:37): [pam] [pam_reply] (0x0200): Returning [4]: System error
to the client
(2020-12-29 12:32:37): [pam] [client_recv] (0x0200): Client disconnected!
Users are in AD via trust. SSSD should not be offline...
(2020-12-29 11:05:35): [be[nwra.com]] [be_run_online_cb] (0x0080): Going
online. Running callbacks.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
3 years, 3 months
