[Freeipa-users] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error
Sumit Bose
sbose at redhat.com
Thu Feb 2 07:27:36 UTC 2017
On Wed, Feb 01, 2017 at 02:41:35PM -0500, Chris Dagdigian wrote:
>
> Update:
>
> Resolved. A bit of googling led me to some good RHEL pages as well as
> mailing list messages from Alex B that were concise and helpful.
>
> To summarize for others who may have this problem:
>
> 1. Don't make changes to sssd.conf if your provider is "ipa" - in this case
> you work only with "ipa idrange-mod" type commands or webUI
>
> 2. The simple solution is to increase the range and restart SSSD after
> blowing away out of date sssd database:
>
> # ipa idrange-mod --base-id=4000000 --range-size=1000000
> EAME.COMPANY.ORG_id_range
> # service sssd stop; rm -f /var/lib/sss/db/*; service sssd start
>
>
> What I actually did on our IPA server was a bit more expansive. EAME was the
> first child domain where I had the SID to UID map issue but it would
> probably not have been the only one so I figured it would be safer to make
> sure that every child domain range had at least 1 million available IDs
>
> Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name"
>
> I went through every single AD child domain and manually reconfigured both
> the "First Posix ID of the range" as well as "Number of IDs in the range" so
> we have at least 1,000,000 ID options in each child domain range:
>
> APAC.COMPANY.ORG 1st-Posix=1800000000 Ids-in-range: 1000000
> EAME.COMPANY.ORG 1st-Posix=1810000000 Ids-in-range: 1000000
> LATAM.COMPANY.ORG 1st-Posix=1820000000 Ids-in-range: 1000000
> NAFTA.COMPANY.ORG 1st-Posix=1830000000 Ids-in-range: 1000000
>
> We are still in testing mode with less than 6 users logging in via IDM
> identities at the moment so it was not disruptive to make this sort of core
> change.
This is a valid way in testing mode. As I wrote in my other mail it is
possible and recommended in production to add additional idrange for a
domain to cover more RIDs if needed.
The difference is that the IPA server already checks if there are no
collisions in the idrange definitions and SSSD on the clients can then
just safely add the new idrange. If a definition of an idrange changes
it might be possible that existing ID-mappings changes, to be on the
safe side here SSSD requires a restart with removing the cache on all
clients.
HTH
bye,
Sumit
>
>
> -Chris
>
>
>
>
>
>
>
> Chris Dagdigian wrote:
> > Hi folks,
> >
> > I've posted here and gotten amazing help on our odd setup with IPA
> > having a 1-way trust to a massive remote AD forest with 90+ domain
> > controllers and lots of child domains.
> >
> > I'm running into a strange issue where I can resolve and manage users in
> > child domain (NAFTA.COMPANY.ORG) but I am getting failures and just
> > discovered an interesting error that relates to resolving a user in the
> > EAME.COMPANY.ORG forrest.
> >
> > However I've also been dragged down the rabbit hole tracking down errors
> > that turned out to be meaningless so I figured my 1st question will be
> > "is this the error should I be focusing on?"
> >
> > This is my situation:
> >
> > 1. "id user at NAFTA.COMPANY.ORG" works perfectly fine - no issues at all
> > with RBAC, sudo and hosting SSH keys etc.
> >
> > 2. "id user at EAME.COMPANY.ORG" fails with "no such user"
> >
> > 3. We did not configure any specific SID-UID mapping rules in sssd.conf
> > as we had assumed we'd use the "default" behavior
> >
> >
> > After digging through the logs I found this which seems VERY clear about
> > the root cause:
> >
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [dp_get_account_info_handler] (0x0200): Got request for
> > [0x1][BE_REQ_USER][1][name=u474418 at eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0040): Object SID
> > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger
> > than the ldap_idmap_range_size. See the "ID MAPPING” section of
> > sssd-ad(5) for an explanation of how to resolve this issue.
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
> > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user]
> > (0x0020): Failed to save user [u474418 at eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users]
> > (0x0040): Failed to store user 0. Ignoring.
> >
> >
> > The error about "Object SID has a RID that is larger than
> > ldap_idmap_range_size .." seems pretty clear. I don't think this is a
> > 'rabbit hole' message - this seems like a real config problem on my end.
> >
> > The problem is that I'm not quite sure what I should configure to
> > resolve this. The man page for sssd-ad covers the topic but does not
> > cover recommended configuration options.
> >
> >
> > Questions for this list:
> >
> > 1) Confirm that the "SID has an RID that is larger ..." error is real
> > and worth chasing down ?
> >
> > 2) My understanding was that by default SSSD will hash SIDs and come up
> > with unique UID and GID ranges that will be consistent across any
> > machine bound to the same IDM mechanism. So I've not configured anything
> > specific related to SID-to-UID mapping as we wanted to go with the
> > default behavior used by SSSD. Obviously the default is not working and
> > I've got to make a change. I just don't know what the recommended change
> > should be. Help appreciated!
> >
> >
> >
> > Config file details are below.
> >
> >
> > Regards,
> > Chris
> >
> >
> >
> >
> >
> > This is the sssd/sssd.conf file on the IPA server:
> >
> > ###----------------------
> >
> > [domain/companyidm.org]
> > ldap_user_principal = nosuchattr
> > subdomain_inherit = ldap_user_principal
> > debug_level = 5
> > krb5_validate = True
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = companyidm.org
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > ipa_hostname = usaeilidmp001.companyidm.org
> > chpass_provider = ipa
> > ipa_server = usaeilidmp001.companyidm.org
> > ipa_server_mode = True
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > [sssd]
> > services = nss, sudo, pam, ssh
> > config_file_version = 2
> >
> > domains = companyidm.org
> > [nss]
> > memcache_timeout = 600
> > homedir_substring = /home
> >
> > [pam]
> > debug_level = 5
> > [sudo]
> >
> > [autofs]
> >
> > [ssh]
> > debug_level = 5
> >
> > [pac]
> >
> > [ifp]
> >
> > ###----------------------
> >
> >
> > This is krb5.conf which handles the child domain and trust things ...
> >
> > [capaths]
> > COMPANYAWS.ORG = {
> > COMPANYIDM.ORG = COMPANYAWS.ORG
> > }
> > COMPANYIDM.ORG = {
> > COMPANYAWS.ORG = COMPANYAWS.ORG
> > SYNGENTA.ORG = COMPANY.ORG
> > EAME.COMPANY.ORG = SYNGENTA.ORG
> > APAC.COMPANY.ORG = SYNGENTA.ORG
> > LATAM.COMPANY.ORG = SYNGENTA.ORG
> > NAFTA.COMPANY.ORG = SYNGENTA.ORG
> > }
> > COMPANY.ORG = {
> > COMPANYIDM.ORG = COMPANY.ORG
> > }
> > EAME.COMPANY.ORG = {
> > COMPANYIDM.ORG = COMPANY.ORG
> > }
> > APAC.COMPANY.ORG = {
> > COMPANYIDM.ORG = COMPANY.ORG
> > }
> > LATAM.COMPANY.ORG = {
> > COMPANYIDM.ORG = COMPANY.ORG
> > }
> > NAFTA.COMPANY.ORG = {
> > COMPANYIDM.ORG = COMPANY.ORG
> > }
> >
> >
> > [logging]
> > default = FILE:/var/log/krb5libs.log
> > kdc = FILE:/var/log/krb5kdc.log
> > admin_server = FILE:/var/log/kadmind.log
> >
> > [libdefaults]
> > default_realm = COMPANYIDM.ORG
> > dns_lookup_realm = true
> > dns_lookup_kdc = true
> > rdns = false
> > ticket_lifetime = 24h
> > forwardable = yes
> > udp_preference_limit = 0
> > default_ccache_name = KEYRING:persistent:%{uid}
> >
> > [realms]
> > COMPANYIDM.ORG = {
> > kdc = usaeilidmp001.companyidm.org:88
> > master_kdc = usaeilidmp001.companyidm.org:88
> > admin_server = usaeilidmp001.companyidm.org:749
> > default_domain = syngentaidm.org
> > pkinit_anchors = FILE:/etccompanyidmipa/ca.crt
> > }
> >
> > [dbmodules]
> > COMPANYIDM.ORG = {
> > db_library = ipadb.so
> > }
> >
> >
> >
> >
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
More information about the Freeipa-users
mailing list