On Thu, Mar 8, 2018 at 5:25 PM, Asif Iqbal <vad...@gmail.com> wrote: > > > On Thu, Mar 1, 2018 at 4:12 AM, Sumit Bose <sb...@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 80974 >> >> or >> >> 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? >
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 <vad...@gmail.com> wrote: >> > > >> > > >> > > >> > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <vad...@gmail.com> wrote: >> > > >> > > >> > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <sb...@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....@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-le...@lists.fedorahosted.org >> _______________________________________________ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@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? > > -- 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-le...@lists.fedorahosted.org
