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)
> @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:
[root@ipa03 ~]# 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
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 ~]#
>
> --
> Cheers,
> Tom K.
>
>
>>
>>>
>>> rob
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>