sssd performance on large domains
by zfnoctis@gmail.com
Hi,
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
1 year, 10 months
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...
4 years
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
4 years, 1 month
Re: Experiencing a bug on users' name and ID
by Asif Iqbal
I still like some help with any workaround in dealing with string.
IT LDAP team do not have any attribute value with real number. Is it
possible to create a local DB to map the mnetid to a real number and then
use that table as a reference for ID mapping? I am not sure if this
discussion should be in developer mailing list.
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" <vadud3(a)gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> I think the next good step would be to show the LDIF and logs of a
> resolution of a single faulty entry, e.g. 80974 which you used earlier as
> an example of an entry that doesn’t work.
>
Here are some logs for this account
dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com
mnetid: 004311
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311]
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][name=4311@ldap]
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(uid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:name=4311@ldap] from reply table
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311]
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913574: Looking up UID:4311@LDAP
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913574: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913574: [UID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913574: Looking up [UID:4311@LDAP] in data provider
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913574: Adding [UID:4311@LDAP] to global negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/UID/4311] to negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913598: Looking up GID:4311@LDAP
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913598: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913598: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913598: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913598: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input
name: 4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #913740: Parsing input name [4311]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name '4311' matched without domain, user is 4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#913740: Setting name [4311]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913740: Looking up 4311@ldap
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913740: Checking negative cache for [4311@ldap]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913740: [4311@ldap] is not present in negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Looking up [4311@ldap] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Object [4311@ldap] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913740: Looking up [4311@ldap] in data provider
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][name=4311@ldap:-]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Looking up [4311@ldap] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Object [4311@ldap] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache_add]
(0x0400): CR #913740: Adding [4311@ldap] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/USER/LDAP/4311@ldap] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913741: Looking up UID:4311@LDAP
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913741: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913741: [UID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913741: Looking up [UID:4311@LDAP] in data provider
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913741: Adding [UID:4311@LDAP] to global negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/UID/4311] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input
name: 4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #913742: Parsing input name [4311]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name '4311' matched without domain, user is 4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#913742: Setting name [4311]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913742: Looking up 4311@ldap
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913742: Checking negative cache for [4311@ldap]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913742: [4311@ldap] does not exist (negative cache)
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913743: Looking up UID:4311@LDAP
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913743: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913743: [UID:4311@LDAP] does not exist (negative cache)
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913764: Looking up GID:4311@LDAP
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913764: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913764: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913764: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913764: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913765: Looking up GID:4311@LDAP
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913765: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913765: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913765: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913765: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
>
> > On 28 Feb 2018, at 01:30, Asif Iqbal <vadud3(a)gmail.com> wrote:
> >
> >
> >
> > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <vadud3(a)gmail.com> wrote:
> >
> >
> > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <sbose(a)redhat.com> wrote:
> > On Mon, Feb 26, 2018 at 10:21:14PM -0500, Asif Iqbal wrote:
> > > I have 300 out of 3000 users whose /home/<username> dir shows uid and
> gid
> > > instead of username and groupname.
> > >
> > > It seems to be behaving like a bug
> > >
> > > As soon I become a user with `sudo su - username' the uid of the home
> dir
> > > changes to username but gid still does not change to groupname.
> > >
> > > I also get an error message, but still successfully become that user
> > >
> > > $ ls -ld /home/mbniels
> > > drwx------. 3 80974 80974 4096 Feb 27 02:15 /home/mbniels
> > >
> > > $ su - mbniels
> > > Last login: Tue Feb 27 02:34:04 UTC 2018 on pts/39
> > > /usr/bin/id: cannot find name for group ID 80974
> > > groups: cannot find name for group ID 80974
> > >
> > > $ ls -ld /home/mbniels
> > > drwx------. 3 mbniels 80974 4096 Feb 27 02:15 /home/mbniels
> > >
> > > Then to check the groups of username I get another error which then
> gets
> > > cleared by next command.
> > >
> > > $ groups mbniels
> > > mbniels : groups: cannot find name for group ID 80974
> > > 80974 users
> > >
> > > $ getent group mbniels
> > > mbniels:*:80974
> > >
> > > $ groups mbniels
> > > mbniels : mbniels users
> > >
> > > It also fixes the gid to groupname
> > >
> > > $ ls -ld /home/mbniels/
> > > drwx------. 3 mbniels mbniels 4096 Feb 27 02:15 /home/mbniels/
> > >
> > > I noticed it reverts after may be within half an hour, not exact sure
> when.
> > > Almost behaves like `quantum entanglement'.
> > > As soon as I try to check by trying to become that user the issue
> > > disappears.
> > >
> > > This is not just cosmetic issue, when the home dir shows ownership with
> > > uid, instead of username, the user fails some commands.
> > >
> > > We just started noticing today, since we just built this box and only
> few
> > > months ago and users are being invited to start using this server
> > >
> > > Some annoying error it is showing like below and user then fails to ssh
> > >
> > > $ ssh remote
> > > No user exists for uid 80974
> > >
> > > I am using centos 7 and sssd 1.15.2
> > >
> > > $ cat /etc/redhat-release
> > > CentOS Linux release 7.4.1708 (Core)
> > >
> > > $ sssd --version
> > > 1.15.2
> > >
> > > Here are some relevant logs
> > > https://paste.fedoraproject.org/paste/gBaZ-Vr8Urh-M5ABpaRNuA
> >
> > It looks like you are not using a plain RFC2307bis LDAP schema. Can you
> > send you sssd.conf and a typical LDAP user and group object?
> >
> > bye,
> > Sumit
> >
> >
> > Here is an ldap user and I using same info as group (sanitized)
> >
> > dn: uid=mbniels,ou=People,dc=example,dc=com
> > roomNumber: 123456
> > departmentNumber: 3.11.3
> > tier1: Technology
> > joblevel: 6
> > legacycompany: G
> > mobile: +11234567890
> > manager: uid=managerid,ou=People,dc=example,dc=com
> > departmentname: TESTING & INTEG
> > costcenter: S0019751
> > companynumber: S001
> > companyname: EXAMPLE COMPANY
> > displayName: FOO, BAR
> > preferredname: Mark
> > docshareaccess: TRUE
> > sAMAccountName: mbniels
> > l: XX
> > street: 123 example ave
> > saploginid: foobar
> > title: LEAD ARCHITECT
> > postalCode: 123456
> > employeeNumber: 00112233
> > mail: foo.bar(a)example.com
> > objectClass: top
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> > objectClass: mnetPerson
> > mnetid: 080974
> > uid: mbniels
> > givenName: Mark
> > st: XX
> > cn: Foo Bar
> > sn: Bar
> > employeeType: Management
> > initials: X
> > nationnumber: USA
> > nationname: United States
> >
> >
> >
> > I am still looking for some help on this.
> >
> >
> >
> > --
> > Asif Iqbal
> > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> >
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
5 years, 6 months
SSSD for one-way trusted AD domain
by Ondrej Valousek
Hi List,
Question, we have joined machine into AD domain B. This domain has one way trust to domain A. No direct connection from domain B network to DCs in domain A is possible.
Can we use SSSD to authenticate members in domain A.
In windows, this works - but can't get it working in Linux via SSSD (Fedora 25, used realmd for AD join).
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, 6 months
sssd 1.16.1 wont start, Centos 7.4
by Lachlan Musicman
Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't
restart.
( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/)
The journalctl -xe shows:
-- Unit sssd.service has begun starting up.
Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up
Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service:
main process exited, code=exited, status=3/NOTIMPLEMENTED
Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to
start System Security Services Daemon.
-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The /var/log/sssd/sssd.log shows
(Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using
function resolv_conf_inotify_cb after delay 1.0
(Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100):
Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq
format [%1$s].
(Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB
File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200):
Timestamp file for unixdev.company.com:
/var/lib/sss/db/timestamps_unixdev.company.com.ldb
(Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register
control with rootdse!
(Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020):
dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied,
message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor":
Permission denied)
(Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using
function resolv_conf_inotify_cb after delay 1.0
(Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100):
Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq
format [%1$s].
(Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB
File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200):
Timestamp file for unixdev.company.com:
/var/lib/sss/db/timestamps_unixdev.company.com.ldb
(Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register
control with rootdse!
(Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020):
dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied,
message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor":
Permission denied)
/var/lib/sss/pipes/private shows
drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 ..
srw------- 1 root root 0 Mar 19 09:21 pam
lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
/var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
srw------- 1 root root 0 Sep 18 2017 sbus-dp_unixdev.company.com.732
srw------- 1 root root 0 Dec 28 09:47 sbus-dp_unixdev.company.com.746
It looks like there's some clean up that's not happening? I don't actually
know what sbus_dp files do, but the top result (pointing to .758) doesn't
exist...
How do I fix this?
Cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
5 years, 8 months
Ubuntu 16.04.4 LTS 4.4.0-108+ and sssd freezes virtual server
by David Hunter
*Guest OS*: Ubuntu 16.04.4 LTS (kernel versions 4.4.0-108 to current 116)
*Virtualization env*: VMWare ESXi 6.0
*Host hardware*: Dell R720
Using SSSD to bind linux servers to the AD domain for authentication. This
was working fine right up to 4.4.0-104. After the update to -108,-109,-112,
or -116, if sssd is enabled OR if it is disabled but then started after a
successful boot and you perform a lookup (i.e. id some_domain_user), the
entire system will freeze, and you have to force a reboot. There's even a
blip in the syslog when it happens.
I increased loglevel to 9 in the sssd.conf file in all the sections, and
then started SSSD and tried to lookup a user. The most meaningful things
I've been able to pull out are:
sssd.log:
(Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000):
Pinging ad.domain.com
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88a9d0
(Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging nss
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x8904c0
(Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging pam
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88ede0
(Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging ssh
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x889710
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88a9d0
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x888c10
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service
ad.domain.com replied to ping
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88ede0
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x890e00
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service pam
replied to ping
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x889710
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x88d5f0
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service ssh
replied to ping
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x8904c0
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x88eae0
(Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service nss
replied to ping
sssd_nss.log:
(Fri Mar 16 13:05:06 2018) [sssd[nss]] [id_callback] (0x0010): The
Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
sssd_ad.domain.com.log:
(Fri Mar 16 13:05:13 2018) [sssd[be[ad.domain.com]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.service.ping on path
/org/freedesktop/sssd/service
(Fri Mar 16 13:05:13 2018) [sssd[be[ad.domain.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Fri Mar 16 13:05:23 2018) [sssd[be[ad.domain.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0xf1e840
(Fri Mar 16 13:05:23 2018) [sssd[be[ad.domain.com]]] [sbus_dispatch]
(0x4000): Dispatching.
sssd_ssh.log:
(Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus
conn: 0x1817880
(Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching.
(Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_message_handler]
(0x2000): Received SBUS method org.freedesktop.sssd.service.ping on
path /org/freedesktop/sssd/service
(Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
sssd.conf:
[sssd]
domains = ad.domain.com
config_file_version = 2
services = nss, pam, ssh
# default_domain_suffix = ad.domain.com
[ssh]
[domain/ad.domain.com]
ad_domain = ad.domain.com
krb5_realm = AD.DOMAIN.COM
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
fallback_homedir = /home/%d/%u
access_provider = ad
# use_fully_qualified_names = True
ad_gpo_access_control = permissive
ad_access_filter = ad.domain.com:(memberOf=CN=Information
Technology,CN=Users,DC=ad,DC=domain,DC=com)
ldap_sasl_authid = ServicePrincipalName | userPrincipalName
ldap_user_ssh_public_key = sshPublicKeys
ldap_user_certificate = noSuchAttribute
Trying to capture boot time logs wasn't successful (with sssd enabled with
systemd). Just a big gap in kernel.log and syslog. Watching the boot
process shows that it hangs at:
Started D-Bus System Messaging Bus
Which appears to be corroborate the problems being indicated in the sssd
logs. Some kinda problem with sssd sending dbus messages, right? If I
revert to -104, all good. Anything above that version, sadness.
What is weird is that I do not have these problems on a test system using
VirtualBox on my MacBook Pro running the same version of Ubuntu 16.04.4
LTS. I'm wondering if this might be a Meltdown related issue, as it
happened with the kernel version that was initially released to address it
(-108). We applied updates to our physical hosts, ESXi and the fixes for
the guest OS. I'm afraid it is a weird confluence of host+vmware+guest OS
problems.
Already tried making sssd.service the last service to start. No change in
behavior other than it hangs later in the boot process.
Any insight or help appreciated! Thanks!
Dave
5 years, 8 months
nss_getpwnam: name 'tom@my.dom@localdomain' does not map into domain 'nix.my.dom'
by TomK
Hey Guy's,
Getting below message which in turn fails to list proper UID / GID on
NFSv4 mounts from within an unprivileged account. All files show up with
owner and group as nobody / nobody when viewed from the client.
Is there a way to structure /etc/idmapd.conf to allow for proper UID /
GID resolution? Or perhaps another solution?
[root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d"
[General]
Verbosity = 7
Domain = nix.my.dom
[Mapping]
[Translation]
[Static]
[UMICH_SCHEMA]
LDAP_server = ldap-server.local.domain.edu
LDAP_base = dc=local,dc=domain,dc=edu
[root@client01 etc]#
Mount looks like this:
nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4
(rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80)
/var/log/messages
Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid
value: tom@my.dom(a)localdomain timeout 600
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling
nsswitch->name_to_uid
Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
'tom@my.dom(a)localdomain' domain 'nix.my.dom': resulting localname '(null)'
Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
'tom@my.dom(a)localdomain' does not map into domain 'nix.my.dom'
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
nsswitch->name_to_uid returned -22
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return
value is -22
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling
nsswitch->name_to_uid
Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name
'nobody(a)nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody'
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid:
nsswitch->name_to_uid returned 0
Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return
value is 0
Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid
value: tom@my.dom(a)localdomain timeout 600
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid:
nsswitch->name_to_gid returned -22
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return
value is -22
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid:
nsswitch->name_to_gid returned 0
Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return
value is 0
Mar 6 00:17:31 client01 systemd-logind: Removed session 23.
Result of:
systemctl restart rpcidmapd
/var/log/messages
-------------------
Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on
demand...
Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand.
Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service...
Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS configuration...
Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration.
Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping service...
Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain:
nix.my.dom
Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list:
'NIX.MY.DOM'
Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: using
domain: nix.my.dom
Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: Realms
list: 'NIX.MY.DOM'
Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: loaded
plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch
Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: loaded plugin
/lib64/libnfsidmap/nsswitch.so for method nsswitch
Mar 5 23:48:51 client01 rpc.idmapd[14118]: Expiration time is 600 seconds.
Mar 5 23:48:51 client01 systemd: Started NFSv4 ID-name mapping service.
Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened
/proc/net/rpc/nfs4.nametoid/channel
Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened
/proc/net/rpc/nfs4.idtoname/channel
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
5 years, 8 months
SSSD and Firewalls
by Roger Mårtensson
Hello!
Got tasked to look at firewall rules and am now wondering if there is a
document anywhere that describes the ports and protocols used by SSSD?
My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636
(tcp) and 3268 (tcp) and 3269 (tcp)
If I search on "Windows Client" and ports I get tons of ports and
port-ranges I may need to open. But what do SSSD use?
5 years, 8 months