[SSSD-users] Re: Could not convert objectSID ... to a UNIX ID

[Sumit Bose]

On Wed, Jul 31, 2019 at 12:24:58PM -0700, Gordon Messmer wrote:
> On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose  wrote:
> > 
> > the version of SSSD you are using should automatically pick a new range
> > if the RID is too large. Can you send your sssd.conf for a start to
> > better understand your setup and see what might preventing SSSD from
> > picking a new range?
> 
> 
> The configuration file is generated by "realm join".  Are there any specific
> patterns you'd like to see from the logs that might provide more
> information?

Hi,

thanks for the config. As a next step please set 'debug_level=9' in the
[domain/...] section, restart SSSD, call 'getent passwd newish_user' and
then send the SSSD domain log from /var/log/sssd. Feel free to send it
to me directly if you prefer to not have it on the list.

bye,
Sumit

> 
> 
> [sssd]
> domains = business.com
> config_file_version = 2
> services = nss, pam
> 
> [domain/business.com]
> debug = 6
> ad_domain = business.com
> krb5_realm = BUSINESS.COM
> realmd_tags = manages-system joined-with-samba
> cache_credentials = False
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = False
> fallback_homedir = /home/business/%u
> access_provider = ad
> 
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID ... to a UNIX ID

[Gordon Messmer]

On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose  wrote:


the version of SSSD you are using should automatically pick a new range
if the RID is too large. Can you send your sssd.conf for a start to
better understand your setup and see what might preventing SSSD from
picking a new range?



The configuration file is generated by "realm join".  Are there any 
specific patterns you'd like to see from the logs that might provide 
more information?



[sssd]
domains = business.com
config_file_version = 2
services = nss, pam

[domain/business.com]
debug = 6
ad_domain = business.com
krb5_realm = BUSINESS.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/business/%u
access_provider = ad

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID ... to a UNIX ID

[Sumit Bose]

On Tue, Jul 30, 2019 at 01:11:44PM -0700, Gordon Messmer wrote:
> I have what I think is an odd situation.  One of the users I support is
> complaining that he is unable to log in to his domain-member Linux system. 
> After enabling debug logging, I've found the error "Could not convert
> objectSID ... to a UNIX ID" in the logs.  The RID is greater than 20, so
> I believe I need to adjust the allowed range and delete the sssd cache, and
> then fix all of the files on the filesystem which are owned by domain users.

Hi,

the version of SSSD you are using should automatically pick a new range
if the RID is too large. Can you send your sssd.conf for a start to
better understand your setup and see what might preventing SSSD from
picking a new range?

bye,
Sumit

> 
> The first odd part is that the user is actually able to log in to this
> system for a while, and is able to log in to other hosts that are also
> running sssd-1.16.2-13.el7_6.8.x86_64 on CentOS 7.6.  If I can figure out
> why that is, I hope that leads us to a solution that isn't as intrusive as
> the one described above.  Does anyone have a guess why this might only
> affect one host right now, and only after a few days of use?
> 
> I'm not sure why our RIDs would be unusually large, unless it is because we
> have users that create short-lived VMs, join them to the domain, and then
> destroy them very frequently.  What is the recommended practice for domains
> with large and rapidly incrementing RIDs?
> 
> What are the implications of increasing the ID map range?  At one point in
> troubleshooting, we saw this in the log.  Does increasing the range come at
> a memory cost?
> (Fri Jul 26 14:31:52 2019) [sssd[be[business.com]]]
> [dp_module_run_constructor] (0x0010): Module [ad] constructor failed [12]:
> Cannot allocate memory
> 
> 
> 
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(sAMAccountName=newish_user)(objectclass=user)(objectSID=*))][DC=business,DC=com].
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]]
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
> errmsg set
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user]
> (0x0400): Save user
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_get_primary_name]
> (0x0400): Processing object newish_user
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user]
> (0x0400): Processing user newish_u...@business.com
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_idmap_sid_to_unix]
> (0x0080): Could not convert objectSID [S-1-5-21----257746] to a
> UNIX ID
> (Tue Jul 30 06:12:32 2019) [sssd[be[business.com]]] [sdap_save_user]
> (0x0020): Failed to save user [newish_u...@business.com]
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID [...] to a UNIX ID

[Francis, Arthur]

This combination also works well on our very large AD:

ldap_idmap_range_min = 20
ldap_idmap_range_max = 200020
ldap_idmap_range_size = 100


_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID [...] to a UNIX ID

[Hans Schou]

Thanks, it is workning now.

The first value I tried for ldap_idmap_range_size was too high.

I then took the RID which I suppose is the last number in the SID:
340002
and gave it a little higher value
40

Remove /var/lib/sss/db and restart sssd.



On 13 January 2016 at 08:36,  wrote:

> > On (12/01/16 14:00), hsc(a)miracle.dk wrote:
> > because RID (relative ID) of user SID is too big.
>
> Which part is the RID?
>
>
> > The default value of range size (ldap_idmap_range_size)
> > is 20. So this user does not fit there.
> >
> > You can increase ldap_idmap_range_size to bigger value,
>
> OK, I tried
>
> > but you will need to remove sssd cache after changing
> > idmap settings. This will results in different UID/GID of users.
>
> I did a:
>   cd /var/lib/sssd/db && rm *
> and stated again. now it says:
>
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [be_get_account_info] (0x0100): Got request for
> [4097][1][idnumber=952940256]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [be_req_set_domain]
> (0x0400): Changing request domain from [corp.acme.com] to [corp.acme.com]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [ad_account_can_shortcut] (0x0080): Mapping ID [952940256] to SID failed:
> [IDMAP domain not found]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [ad_account_info_handler] (0x0400): Cannot determine the right domain:
> Input/output error
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [users_get_send]
> (0x0080): [952940256] did not match any configured ID mapping domain
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [sysdb_search_user_by_uid] (0x0400): No such entry
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [sysdb_delete_user]
> (0x0400): Error: 2 (No such file or directory)
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [be_get_account_info] (0x0100): Got request for
> [4097][1][idnumber=952940256]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [be_req_set_domain]
> (0x0400): Changing request domain from [corp.acme.com] to [
> ad-root.acme.com]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [ad_account_can_shortcut] (0x0080): Mapping ID [952940256] to SID failed:
> [IDMAP domain not found]
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [ad_account_info_handler] (0x0400): Cannot determine the right domain:
> Input/output error
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [users_get_send]
> (0x0080): [952940256] did not match any configured ID mapping domain
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]]
> [sysdb_search_user_by_uid] (0x0400): No such entry
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [sysdb_delete_user]
> (0x0400): Error: 2 (No such file or directory)
> (Wed Jan 13 07:31:06 2016) [sssd[be[corp.acme.com]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
>
> > ＠see also
> > man sssd-ldap -> ldap_idmap_range_size
> > man sssd-ldap -> ID MAPPING -> 3rd paragraph
>
> Thanks. I seems like it should be possible to calcutae the right size in
> some way.
>
> ./hans
> ___
> sssd-users mailing list
> sssd-users@lists.fedorahosted.org
>
> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
>



-- 

Venlig hilsen - best regards
*Hans Schou*
Konsulent
Mobil: 53747192
E-mail: h...@miracle.dk




Miracle ⅍, Borupvang 2C, 2750 Ballerup
i...@miracle.dk - www.miracle.dk 
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID [...] to a UNIX ID

[Lukas Slebodnik]

On (12/01/16 14:00), h...@miracle.dk wrote:
>Hi
>
>I have two users in the AD. Only one of them can login with ssh or su on the 
>Linux server.
>
>The user admjoin is the one made the "realm join" and he can login:
>/var/log/sssd/sssd_corp.acme.com.log:
>Mapping user [AdmJoin] objectSID 
>[S-1-5-21-2031436270-1094658265-1854952973-140256] to unix ID
>Adding original memberOf attributes to [AdmJoin].
>
>And avgjoe can not login:
>Mapping user [AvgJoe] objectSID 
>[S-1-5-21-2031436270-1094658265-1854952973-340002] to unix ID
>Could not convert objectSID [S-1-5-21-2031436270-1094658265-1854952973-340002] 
>to a UNIX ID
>
because RID (relative ID) of user SID is too big.

The default value of range size (ldap_idmap_range_size)
is 20. So this user does not fit there.

You can increase ldap_idmap_range_size to bigger value,
but you will need to remove sssd cache after changing
idmap settings. This will results in different UID/GID of users.

@see also
man sssd-ldap -> ldap_idmap_range_size
man sssd-ldap -> ID MAPPING -> 3rd paragraph

LS


>Why can user avgjoe not log in?
>(and why are the ObjectSID the same (if relevant)?)
>
>Note that when doing a "su - avgjoe" the AD converts it to AvgJoe in log-file, 
>as defined on the AD-server.
>
>I guess there is around 2 users defined in the AD. User AdmJoin was 
>created when the system was setup, and user AvgJoe is added recently (he might 
>have a very high numeric id).
>
>[sssd]
>domains = corp.acme.com
>config_file_version = 2
>services = nss, pam, ssh, sudo
>debug_level = 7
>
>[domain/corp.acme.com]
>ad_domain = corp.acme.com
>krb5_realm = CORP.ACME.COM
>realmd_tags = manages-system joined-with-samba
>#cache_credentials = True
>cache_credentials = False
>id_provider = ad
>krb5_store_password_if_offline = True
>default_shell = /bin/bash
>ldap_id_mapping = True
>use_fully_qualified_names = False
>fallback_homedir = /home/%d/%u
>access_provider = ad
>debug_level = 7
>ldap_idmap_range_min = 20
>ldap_idmap_range_max = 200020
>ldap_idmap_range_size = 20
>
>Any help is much appreciated.
>
>best regards
>Hans
>___
>sssd-users mailing list
>sssd-users@lists.fedorahosted.org
>https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org