Was the cache. Ran the rm-f /var/lib/sss/db/* to blow it up and restarted.
Thanks for the help guys! Appreciated.
Sent from my iPhone
On Feb 24, 2019, at 2:02 PM, Tom via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Sent from my iPhone
>> On Feb 24, 2019, at 12:32 PM, Alexander Bokovoy via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>>
>>> On su, 24 helmi 2019, TomK wrote:
>>>> On 2/24/2019 4:53 AM, Alexander Bokovoy via FreeIPA-users wrote:
>>>>> 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)
>>>>>> @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.
>>>
>>
>> Tried using ipa trust-mod. No luck, got a few errors like this:
>>
>> ipa: ERROR: attribute "ipaRangeType" not allowed
>>
>> and stopped. Used ldapmodify to set the ipaRangeType, that worked but the ID
still shows up as 10000 for sam(a)abc.123.
>>
>> Ultimately removed the trust, ID Ranges objects via the UI and recreated the
trust:
>>
>> ipa-adtrust-install --netbios-name=ABC -a "SECRET"
>>
>> [root@ipa03 ~]# ipa trust-add -vv --type=ad abc.123 --admin Administrator
--password --two-way=true
>> ipa: INFO: trying
https://ipa03.b.abc.123/ipa/session/json
>> ipa: INFO: Request: {
>> "id": 0,
>> "method": "ping",
>> "params": [
>> [],
>> {}
>> ]
>> }
>> ipa: INFO: Response: {
>> "error": null,
>> "id": 0,
>> "principal": "admin(a)B.ABC.123",
>> "result": {
>> "messages": [
>> {
>> "code": 13001,
>> "data": {
>> "server_version": "2.230"
>> },
>> "message": "API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.230",
>> "name": "VersionMissing",
>> "type": "warning"
>> }
>> ],
>> "summary": "IPA server version 4.6.4. API version
2.230"
>> },
>> "version": "4.6.4"
>> }
>> Active Directory domain administrator's password:
>> ipa: INFO: [try 1]: Forwarding 'trust_add/1' to json server
'https://ipa03.b.abc.123/ipa/session/json'
>> ipa: INFO: Request: {
>> "id": 0,
>> "method": "trust_add/1",
>> "params": [
>> [
>> "abc.123"
>> ],
>> {
>> "bidirectional": true,
>> "realm_admin": "Administrator",
>> "realm_passwd": "This389[-)",
>> "trust_type": "ad",
>> "version": "2.230"
>> }
>> ]
>> }
>> ipa: INFO: Response: {
>> "error": null,
>> "id": 0,
>> "principal": "admin(a)B.ABC.123",
>> "result": {
>> "result": {
>> "cn": [
>> "abc.123"
>> ],
>> "ipantflatname": [
>> "ABC"
>> ],
>> "ipantsupportedencryptiontypes": [
>> "28"
>> ],
>> "ipanttrustdirection": [
>> "3"
>> ],
>> "ipanttrusteddomainsid": [
>> "S-1-5-21-1803828911-4163023034-2461700517"
>> ],
>> "ipanttrustpartner": [
>> "abc.123"
>> ],
>> "ipanttrustposixoffset": [
>> "0"
>> ],
>> "ipanttrusttype": [
>> "2"
>> ],
>> "trustdirection": [
>> "Two-way trust"
>> ],
>> "truststatus": [
>> "Established and verified"
>> ],
>> "trusttype": [
>> "Active Directory domain"
>> ]
>> },
>> "summary": "Added Active Directory trust for realm
\"abc.123\"",
>> "value": "abc.123"
>> },
>> "version": "4.6.4"
>> }
>> ------------------------------------------------
>> Added Active Directory trust for realm "abc.123"
>> ------------------------------------------------
>> Realm name: abc.123
>> Domain NetBIOS name: ABC
>> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
>> Trust direction: Two-way trust
>> Trust type: Active Directory domain
>> Trust status: Established and verified
>> [root@ipa03 ~]#
>>
>>
>> So I find the idrange using your command, which seems fine btw:
>>
>>
>> [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
>> First RID of the corresponding RID range: 155600000
>> Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517
>> Range type: Active Directory domain range
>>
>> 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 ~]# id sam(a)abc.123
>> uid=10000(sam(a)abc.123) gid=10000(nixgrp(a)abc.123)
groups=10000(nixgrp@abc.123),10001(cdhadmins(a)abc.123),1163400005(cdhadmins),1163400004(nixgrp)
>> [root@ipa03 ~]#
>>
>> Tried to create a user without any UNIX Attributes in AD:
>>
>> [root@ipa03 ~]# id notsam(a)abc.123
>> id: notsam(a)abc.123: no such user
>> [root@ipa03 ~]#
>>
>>
>> And then after some time / reboot it's back to POSIX:
>>
>> [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 ~]#
>>
>>
>> I see POSIX ranges are back. So I recreate the trust and all mappings forcing
ipa-ad-trust .
>>
>> ipa -vv trust-add --type=ad abc.123 --admin Administrator --password
--two-way=true --range-type=ipa-ad-trust
>>
>> Redo all the group mappings. Restart. Same thing. ID's are still what
I've set in AD via UNIX Attributes.
>>
>> This time however, the ranges object hasn't reverted to POSIX (yet).
>>
>> [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
>> First RID of the corresponding RID range: 155600000
>> Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517
>> Range type: Active Directory domain range
>>
>> 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 ~]#
>>
>> But the ID's still remain as they were:
>>
>> [root@ipa03 ~]# id sam(a)abc.123
>> uid=10000(sam(a)abc.123) gid=10000(nixgrp(a)abc.123)
groups=10000(nixgrp@abc.123),10001(cdhadmins(a)abc.123),1163400005(cdhadmins),1163400004(nixgrp)
>> [root@ipa03 ~]#
>>
>> Just to test, created a new user in AD without any UNIX Attributes but of course
that's not visible from IPA:
>>
>> [root@ipa03 ~]# id notsam(a)abc.123
>> id: notsam(a)abc.123 no such user
>> [root@ipa03 ~]#
>>
>> Going to dig into the logs in a bit and see what they say.
> Please do look into the logs. Don't forget to remove sssd caches when
> changes happen to ID ranges and restart SSSD.
>
> However, one thing I wanted to note is that there is *no* code in IPA
> that would manipulate ID range type after establishing trust. Once ID
> range is created we don't touch it _at all_.
>
> So I suspect you have some automation that breaks things.
No automation at all. All vanilla stuff. I’ll clear the cache and retry. I’ll collect
the logs from a brand new attempt and share in a bit.
Thanks Alex!
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> _______________________________________________
> 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...