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 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 <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 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@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

--

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?