4:56 a.m.
On ma, 14 joulu 2020, lejeczek via FreeIPA-users wrote:
On 14/12/2020 10:22, Alexander Bokovoy wrote:
>On ma, 14 joulu 2020, lejeczek via FreeIPA-users wrote:
>>Hi guys,
>>
>>I must be missing something I hope. This should just work, right?
>>
>>$ ipa migrate-ds --bind-dn="cn=Directory Manager"
>>--user-container=cn=users,cn=accounts
>>--group-container=cn=groups,cn=accounts
>>--group-objectclass=posixgroup --with-compat ldap://10.0.0.6
>>
>>Prior to above, on the target IPA I run:
>>
>>$ ipa-adtrust-install
>>
>>Source IPA is: VERSION: 4.6.8, API_VERSION: 2.237
>>Target is: VERSION: 4.8.7, API_VERSION: 2.239
>>
>>$ smbclient -L //love.ccn.mine.domain -Ume
>>lp_load_ex: changing to config backend registry
>>Unknown parameter encountered: "includes"
>>Enter CCN\me's password:
>>session setup failed: NT_STATUS_INVALID_SID
>>
>>Any suggestions as what is (not but should)happening are greatly
>>appreciated.
>
>Your migrated user accounts contain ipaNTSecurityIdentifier pointing
>to
>older IPA's domain SID which is different from your new IPA's domain
>SID.
>
>Why do you need to migrate this way instead of adding a new replica
>and
>then moving all services to it and decommissioning old 4.6 replicas?
>
I was hoping to get a "fresh" start.
My "old" domain is bit clunky - I have one master which I cannot
"clean up".
That master still lists a removed master which does not exists any
more.
$ ipa-replica-manage list
shows, and it's the only "place" where I see that non-existent master,
whereas other master do not.
If I try, on that "dirty" master (love is "non-existent"):
$ ipa-replica-manage del love.ccn.mine.domain
Server removal aborted:
Replication topology in suffix 'domain' is disconnected:
Topology does not allow server drunk.ccnr.ceb.private.cam.ac.uk to
replicate with servers:
love.ccn.mine.domain
Topology does not allow server love.ccn.mine.domain to replicate with
servers:
punch.ccn.mine.domain
drunk.ccn.mine.domain
Topology does not allow server punch.ccn.mine.domain to replicate with
servers:
love.ccn.mine.domain.
Is there a why to make "migrate-ds" succeed?
Frankly, I don't know. You'd need to manipulate *a lot* of internal LDAP
representation of IPA.
For example: Domain SID needs to be changed in all existing
ipaNTSecurityIdentifier values. At the same time, users/groups migrated
from old setup would have old uidNumber/gidNumber values, so RIDs in the
SID will have those old values which depend on the old IPA ID ranges
which you don't have in the new setup. So, new setup needs old IPA ID
range copied over. That will not fix all the problems because you'd need
to somehow coordinate RID values with new ID range used for new
users/groups in new IPA setup too.
And these are just starting points.
many thanks, L.
_______________________________________________
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://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/freeipa-users@lists.fedoraho...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland