On la, 23 helmi 2019, TomK via FreeIPA-users wrote:
On 2/22/2019 9:51 AM, Alexander Bokovoy via FreeIPA-users wrote:
>On Fri, 22 Feb 2019, TomK via FreeIPA-users wrote:
>>On 2/20/2019 10:58 PM, TomK wrote:
>>>On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote:
>>>>TomK via FreeIPA-users wrote:
>>>>>Hey All,
>>>>>
>>>>>Getting a scenario where the hostname doesn't resolve to the new
IP if
>>>>>the VM is recreated multiple times against an IPA server.
>>>>>
>>>>>I've tried clearing the caches on the clients but no luck.?? I
have to
>>>>>allow a specific amount of time to pass before I can use the DNS name
>>>>>that now points to a different (new) IP that was assigned via DHCP.
>>>>>
>>>>>This apparently also impacts the automounter and it won't work
until
>>>>>much later either.?? I won't be able to use the NFS mount
configured
>>>>>until then.?? On initial login users need to wait about 5
>>>>>minutes before
>>>>>they can login with home folder set to / instead as a result:
>>>>>
>>>>>Using username "abc.123\sam".
>>>>>Using keyboard-interactive authentication.
>>>>>Password:
>>>>>Creating home directory for abc.123\sam.
>>>>>Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76
>>>>>Could not chdir to home directory /n/abc.123/sam: No such
>>>>>file or directory
>>>>>-sh-4.2$
>>>>>
>>>>>Has anyone seen this scenario before and have a general high
>>>>>level idea
>>>>>where I could start to poke??? Seems to me like a DNS Cache Refresh
or
>>>>>Timeout but not sure about the specifics.
>>>>>
>>>>>/n/abc.123/sam exists and mount works off of other hosts
>>>>>that have been
>>>>>around for a while.
>>>>>
>>>>
>>>>I'd guess it is the DNS TTL. You'd need to lower that in the
>>>>DNS server.
>>>>
>>>>I assume this is some sort of dev or qe box that is re-provisioned
>>>>frequently?
>>>
>>>That's correct.
>>
>>Fixed. At least the above immediate issue. Ended up restarting
>>the client and the NFS services on the NFS cluster one by one.
>>
>>I notice now as well that the ID assigned to AD users has changed
>>in the latest versions of SSSD / IPA. The UNIX Attributes that
>>were always set in the AD DC are now being respected:
>>
>>OLD SSSD / IPA:
>>
>># id sam(a)abc.123
>>uid=155601104(sam(a)abc.123) / gid=155601107(nixgrp(a)abc.123)
>>
>>NEW SSSD / IPA:
>># id sam(a)abc.123
>>uid=10000(sam(a)abc.123) / gid=10000(nixgrp(a)abc.123)
>>(a)abc.123)
>This is probably due to you not forcing a specific ID range type when
>creating the trust so it picked up what was able to autodetect, eg.
>posix attributes in AD.
>
>>Would the ID's on the old IPA / SSSD setup be retained if the old
>>IPA cluster were to be upgraded?
>The change only applies when you are removing trust to AD and existing
>ID ranges. Otherwise it should not change at all.
>
>Show your 'ipa idrange-find' output.
Yes. Different ranges exist:
[root@ipa03 ~]# ipa idrange-find
----------------
2 ranges matched
----------------
Range name: ABC.123_id_range
First Posix ID of the range: 10000
Number of IDs in the range: 200000
Domain SID of the trusted domain:
S-1-5-21-1803828911-4163023034-2461700517
Range type: Active Directory trust range with POSIX attributes
Range name: B.ABC.123_id_range
First Posix ID of the range: 1163400000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------
[root@ipa03 ~]#
Older cluster:
[root@ipa01 ~]# ipa idrange-find
----------------
2 ranges matched
----------------
Range name: ABC.123_id_range
First Posix ID of the range: 155600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain:
S-1-5-21-1803828911-4163023034-2461700517
Range type: Active Directory domain range
Range name: A.ABC.123_id_range
First Posix ID of the range: 1746600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------
[root@ipa01 ~]#
I did try to modify the baseID using:
ipa idrange-mod ABC.123_id_range --base-id 155600000
and
[root@ipa03 ~]# ldapmodify -H
ldapi://%2fvar%2frun%2fslapd-B-ABC-123.socket << EOF
> dn: cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123
> changetype: modify
> replace: ipabaserid
> ipabaserid: 155600000
> -
> replace: ipaBaseID
> ipaBaseID: 155600000
> -
> replace: ipaIDRangeSize
> ipaIDRangeSize: 200000
> -
> replace: ipaNTTrustedDomainSID
> ipaNTTrustedDomainSID: S-1-5-21-1803828911-4163023034-2461700517
> -
> replace: ipaRangeType
> ipaRangeType: ipa-ad-trust-posix
> -
> EOF
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123"
[root@ipa03 ~]#
but even though the number changed, it still shows the earlier 10000
ID for sam(a)abc.123. So I'm missing something. Checked the above and
now see modified ranges even though the ID for sam is still 10000:
Not sure what you
modified. You need to get rid of 'ipa-ad-trust-posix'
because it is the type that picks the POSIX ID data from AD DCs and is
what you don't want. Your ldapmodify above is definitely does it the
other way around.
Fix your idrange ABC.123_id_range, restart sssd on IPA masters and
clients, then SSSD should pick up new range settings.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland