On Thu, Mar 15, 2018 at 4:42 AM, Sumit Bose <sbose@redhat.com> wrote:
On Wed, Mar 14, 2018 at 03:42:28PM -0400, Asif Iqbal wrote:
> On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose <sbose@redhat.com> wrote:
>
> > On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
> > > On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal <vadud3@gmail.com> wrote:
> > >
> > > >
> > > >
> > > > On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose <sbose@redhat.com> wrote:
> > > >
> > > >> On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
> > > >> > I still like some help with any workaround in dealing with string.
> > > >> >
> > > >> > IT LDAP team do not have any attribute value with real number. Is it
> > > >> > possible to create a local DB to map the mnetid to a real number and
> > > >> then
> > > >> > use that table as a reference for ID mapping? I am not sure if this
> > > >> > discussion should be in developer mailing list.
> > > >>
> > > >> You might want to try local overrides, see man sss_override for
> > details.
> > > >>
> > > >
> > > > Let me read up on it real quick and explore that. What should I be
> > looking
> > > > for?
> > > > How to override mnetid attribute value type from string to integer?
> > > >
> > > >
> > >
> > > So I see 5% of current users have mnetid with leading 0.
> > >
> > > So I never used sss_override. How do I use sss_override to make mnetid
> > > 004311
> > > to work with sss when ldap id mapping tries to map 4311 instead?
> > >
> > > Appreciate your help!
> >
> > I haven't tested it with your setup but
> >
> >     sss_override user_add mwvande --uid 4311 --gid 4311
> >     sss_override group_add mwvande --gid 4311
> >
> > should create the needed override data so that user and group mwvande
> > can be looked up with the ID 4311.
> >
>
>
> So I can lookup by 4311 after this. Very nice!
>
> Do I need to restart sssd after these two commands?

You have to restart SSSD after adding the first overrides to switch on
the override handling. If you add additional override later on you do
not have to restart SSSD, but you might need to wait until some cache
timeouts are passed before the overridden values are shown.


I have a user today complained whose mnetid has leading 0s

[mwvande@example:]$ ssh sgx2-brdr-01

No user exists for uid 4311

I already have the sss_override ran last week for 100 users last week and sssd was restarted.





bye,
Sumit

>
>
>
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >> As an alternative you might want to try to enable enumeration. After
> > the
> > > >> initial enumeration run is done all users and groups are already in
> > > >> SSSD's cache and lookups by id should work. But I'm not sure if
> > > >> enumeration can handle you setup where user and groups are defined by
> > > >> the same LDAP object.
> > > >>
> > > >>
> > > > During initial setup, before this server was in production, I tried
> > > > enumeration on
> > > > and I think login were failing and it was doing ldap query for 2500
> > users
> > > > and
> > > > almost was not responding. So kind of risky to go that path, since most
> > > > users'
> > > > mnetd id do not have leading `0' and I might add more problem than
> > > > solution :-)
> > > >
> > > >
> > > >
> > > >> Finally, if it is possible to remove the leading '0's from mnetid it
> > > >> should work as well because then '(mnetid=4311)' would match as string
> > > >> as well.
> > > >>
> > > >>
> > > > I think I have the worst IT  LDAP team. They will not change there
> > schema
> > > > and
> > > > remove any leading 0s from mnetid.
> > > >
> > > > Might be little off-topic, but I am not sure if we could have a ldap
> > sync
> > > > all attributes
> > > > to a local ldap server minus the mnetid and we populate that with
> > numbers.
> > > > Probably
> > > > also add more work to address few user accounts with leading 0s
> > > >
> > > >
> > > > bye,
> > > >> Sumit
> > > >>
> > > >> >
> > > >> > Appreciate any help
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Mar 8, 2018 11:29 PM, "Asif Iqbal" <vadud3@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > 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 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.fedorah
> > > >> osted.org
> > > >> > > _______________________________________________
> > > >> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > >> > > To unsubscribe send an email to sssd-users-leave@lists.fedorah
> > > >> osted.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?
> > > >>
> > > >> > _______________________________________________
> > > >> > 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?
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> >
>
>
>
> --
> 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



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