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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
