On Thu, Mar 8, 2018 at 5:25 PM, Asif Iqbal <vadud3(a)gmail.com> wrote:
On Thu, Mar 1, 2018 at 4:12 AM, Sumit Bose <sbose(a)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 <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.fedorah
>
osted.org
> > _______________________________________________
> > 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?
--
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?