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
Appreciate any help
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 80974I 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
Appreciate any help
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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
I am using rfc2307bis
Here is the sssd.conf (sanitized)
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss,pam,sudo domains = LDAP
[nss] reconnection_retries = 3 filter_groups = root,wheel filter_users = root
[pam] reconnection_retries = 3 offline_credentials_expiration = 0 pam_verbosity = 3
[sudo]
[domain/LDAP] chpass_provider = ldap access_provider = ldap id_provider = ldap case_sensitive = False ldap_schema = rfc2307bis ldap_search_base = ou=People,dc=example,dc=com ldap_uri = ldaps://192.168.1.100, ldaps://192.168.1.101 ldap_access_order = filter ldap_access_filter = (&(objectClass=mnetPerson)(nationnumber=USA)) ldap_user_uid_number = mnetid ldap_user_gid_number = mnetid ldap_group_gid_number = mnetid ldap_group_object_class = inetOrgPerson ldap_user_object_class = mnetPerson ldap_user_fullname = uid ldap_group_name = uid ldap_network_timeout = 3 ldap_tls_reqcert = allow ldap_tls_cacert = /etc/ssl/certs/hostca.cer ldap_chpass_update_last_change = true ldap_pwd_policy = none ldap_account_expire_policy = none ldap_default_authtok_type = password ldap_default_bind_dn = uid=binduid,ou=people,dc=example,dc=com ldap_default_authtok = secretsanitized
auth_provider = ldap
krb5_server = 192.168.1.102:88, 192.168.1.103:88 krb5_backup_server = 192.168.1.102 krb5_realm = IT.INTRANET krb5_auth_timeout = 15
cache_credentials = true default_shell = /bin/bash override_homedir = /home/%u
Appreciate any help
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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
Appreciate any help
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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.
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.
On 28 Feb 2018, at 01:30, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Wed, Feb 28, 2018 at 10:27:20PM +0100, Jakub Hrozek 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.
I would expect the lookups by UID or GID do not work. Does
getent passwd 80974
or
getent group 80974
return anything with an empty cache?
objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: mnetPerson mnetid: 080974 uid: mbniels
What is the schema definition of mnetid on the LDAP server? Since it is starting with a '0' I would expect that it is using some string syntax and is not an integer from the LDAP schema point of view.
SSSD treats the UID and GID as numerical values and expects that the LDAP server treats them as numerical values as well as defined in RFC2307/RFC2307bis. So a part of the search filter will be (mnetid=80974). But if mnetid is defined as string in the schema then the attribute
mnetid: 080974
will not match the search filter because from the string-comparison perspective the leading '0' is missing in the search filter.
If the user or group is looked up by name first SSSD will write the proper numerical value 80974 into is cache. But if the cached entry is expired and a search by UID or GID is processed next the cached entry will be removed because there is no matching entry found on the server and SSSD has to assume that it was removed on the server.
To get around this the proper solution would be to use an integer attribute for the UID/GID on the LDAP server. I cannot tell how easy it would be in your environment to change the schema definition of mnetid (since the attribute already exists I guess you have to dump the content, change the schema and freshly import all data). Additionally I cannot tell if other applications might depend on the leading '0' in mnetid. So I guess the most easy short term solution would be to add a new integer attribute and sync this attribute with the numerical value from mnetid.
HTH
bye, Sumit
On 28 Feb 2018, at 01:30, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Thu, Mar 1, 2018 at 4:12 AM, Sumit Bose sbose@redhat.com wrote:
On Wed, Feb 28, 2018 at 10:27:20PM +0100, Jakub Hrozek 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.
I would expect the lookups by UID or GID do not work. Does
getent passwd 80974or
getent group 80974
Yes you are correct..
$ getent passwd 4311
$ getent group 4311
$ id 4311 id: 4311: no such user
$ ls -ld /home/mwvande drwx------. 33 4311 4311 4096 Feb 20 19:12 /home/mwvande
$ getent passwd mwvande mwvande:*:4311:4311:mwvande:/home/mwvande:/bin/bash
$ getent group mwvande mwvande:*:4311:
$ id 4311 uid=4311(mwvande) gid=4311(mwvande) groups=4311(mwvande),100(users)
$ ls -ld /home/mwvande drwx------. 33 mwvande mwvande 4096 Feb 20 19:12 /home/mwvande
Yes it is treating as text.
$ ldsmnetid 4311 uid (empty)
$ ldsmnetid 004311 uid dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com uid: mwvande
$ cat ldsmnetid .... ldapsearch -LLL -x -D $_binddn -y $_pass -z $_max -l $_timeout -s one "(&(objectClass=mnetPerson)(mnetid=$param))" "$@"
That sucks.. Trying to find out which LDAP attribute is integer. Waiting for a response from IT LDAP team. Any other workaround?
return anything with an empty cache?
objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: mnetPerson mnetid: 080974 uid: mbniels
What is the schema definition of mnetid on the LDAP server? Since it is starting with a '0' I would expect that it is using some string syntax and is not an integer from the LDAP schema point of view.
SSSD treats the UID and GID as numerical values and expects that the LDAP server treats them as numerical values as well as defined in RFC2307/RFC2307bis. So a part of the search filter will be (mnetid=80974). But if mnetid is defined as string in the schema then the attribute
mnetid: 080974
will not match the search filter because from the string-comparison perspective the leading '0' is missing in the search filter.
If the user or group is looked up by name first SSSD will write the proper numerical value 80974 into is cache. But if the cached entry is expired and a search by UID or GID is processed next the cached entry will be removed because there is no matching entry found on the server and SSSD has to assume that it was removed on the server.
To get around this the proper solution would be to use an integer attribute for the UID/GID on the LDAP server. I cannot tell how easy it would be in your environment to change the schema definition of mnetid (since the attribute already exists I guess you have to dump the content, change the schema and freshly import all data). Additionally I cannot tell if other applications might depend on the leading '0' in mnetid. So I guess the most easy short term solution would be to add a new integer attribute and sync this attribute with the numerical value from mnetid.
HTH
bye, Sumit
On 28 Feb 2018, at 01:30, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Thu, Mar 8, 2018 at 5:25 PM, Asif Iqbal vadud3@gmail.com wrote:
On Thu, Mar 1, 2018 at 4:12 AM, Sumit Bose sbose@redhat.com wrote:
On Wed, Feb 28, 2018 at 10:27:20PM +0100, Jakub Hrozek 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.
I would expect the lookups by UID or GID do not work. Does
getent passwd 80974or
getent group 80974Yes you are correct..
$ getent passwd 4311
$ getent group 4311
$ id 4311 id: 4311: no such user
$ ls -ld /home/mwvande drwx------. 33 4311 4311 4096 Feb 20 19:12 /home/mwvande
$ getent passwd mwvande mwvande:*:4311:4311:mwvande:/home/mwvande:/bin/bash
$ getent group mwvande mwvande:*:4311:
$ id 4311 uid=4311(mwvande) gid=4311(mwvande) groups=4311(mwvande),100(users)
$ ls -ld /home/mwvande drwx------. 33 mwvande mwvande 4096 Feb 20 19:12 /home/mwvande
Yes it is treating as text.
$ ldsmnetid 4311 uid (empty)
$ ldsmnetid 004311 uid dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com uid: mwvande
$ cat ldsmnetid .... ldapsearch -LLL -x -D $_binddn -y $_pass -z $_max -l $_timeout -s one "(&(objectClass=mnetPerson)(mnetid=$param))" "$@"
That sucks.. Trying to find out which LDAP attribute is integer. Waiting for a response from IT LDAP team. Any other workaround?
It looks like employeenumber is also a string. I guess need another solution then.
return anything with an empty cache?
objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: mnetPerson mnetid: 080974 uid: mbniels
What is the schema definition of mnetid on the LDAP server? Since it is starting with a '0' I would expect that it is using some string syntax and is not an integer from the LDAP schema point of view.
SSSD treats the UID and GID as numerical values and expects that the LDAP server treats them as numerical values as well as defined in RFC2307/RFC2307bis. So a part of the search filter will be (mnetid=80974). But if mnetid is defined as string in the schema then the attribute
mnetid: 080974
will not match the search filter because from the string-comparison perspective the leading '0' is missing in the search filter.
If the user or group is looked up by name first SSSD will write the proper numerical value 80974 into is cache. But if the cached entry is expired and a search by UID or GID is processed next the cached entry will be removed because there is no matching entry found on the server and SSSD has to assume that it was removed on the server.
To get around this the proper solution would be to use an integer attribute for the UID/GID on the LDAP server. I cannot tell how easy it would be in your environment to change the schema definition of mnetid (since the attribute already exists I guess you have to dump the content, change the schema and freshly import all data). Additionally I cannot tell if other applications might depend on the leading '0' in mnetid. So I guess the most easy short term solution would be to add a new integer attribute and sync this attribute with the numerical value from mnetid.
HTH
bye, Sumit
On 28 Feb 2018, at 01:30, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Asif Iqbal -
Jakub Hrozek -
Sumit Bose