On Thu, Mar 1, 2018 at 4:12 AM, Sumit Bose <[email protected]> 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? > 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 <[email protected]> wrote: > > > > > > > > > > > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <[email protected]> wrote: > > > > > > > > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <[email protected]> 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: [email protected] > > > 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 -- [email protected] > > > To unsubscribe send an email to sssd-users-leave@lists. > fedorahosted.org > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- 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 -- [email protected] To unsubscribe send an email to [email protected]
