So, I think we are ready, I leave you the ground to present this free APA to free APA migration
too.
Okay, thank you very much.
So, hello everyone.
I'm Francesca Trevino.
I work as a record, as part of the Unity Management team, as a free APA team member.
And today, and super happy to introduce something new.
And it is all about a new tool.
For the free APA project, that simplifies full migration
between free APA deployments.
And the best part of it is that it's all quite implemented.
And it's available as part of Fedora and also you can find the tool in dwell.
And most importantly, it works.
So, yeah, you see, a couple of more names in the slide.
My working colleague Rob, he was the one that signed this wonderful tool.
And also Mark Greennode.
He's the main developer of the 399DS project.
And he proved it to life, this wonderful tool.
So, before I started, I just want to spend a few minutes talking about some of the background
and the basic, very basic aspects about migration.
In general, you know, the migration is really complex topic.
You can have multiple approaches depending on your needs.
So, you might simply want to update your free PE version
because of, yes, to fix something, a bag or you might want to upgrade to another release version.
So, we don't really use this migration term here.
We just call update because you are in the system.
You just basically operate the RPMs and then you are getting the new release.
And you're not moving any data.
If there are changes in this schema or the classes of something,
the upgrade procedure is supposed to fix the data.
But we are not migrating anything.
So, that is not considered as a migration is the as an update.
Another just case is when the administrator needs to move to a new major operating system.
Okay, so this is kind of different from the other case because if you move to from real late for instance to real night.
You are not able to do a simple RPM upgrade.
This is not possible, right?
So, you need to go for a more complex procedure such as for instance an in place upgrade.
And in this case, you just rely on more complex tool in that this capable of upgrading the whole operating system.
And then installing the all the new version in.
In this case, again, we don't say that this is our migration because you are in the same system.
And then you are not moving any data from one deployment to another.
But for this specific use case, we talk about the upgrade procedure.
Specifically for identity management, we have a way where you cannot replica to the server.
And as soon as you have the replica, all the data will be replicated to the replica.
So then the next step is just to simply upgrade that replica to be the master.
And then do the commission, the other server and IDM server.
And in this case, yes, in this case, we use migration.
Because we are moving the data from one deployment to another one.
So then for all the other cases, I'm talking about that you might be changing hardware or moving from different platforms.
You might want to change from very metal to virtualization, virtual machines or cloud infrastructure.
I mean, there are so many use cases where we, where you need to do up pure migration of the data.
So for all those cases, then yes, we also use the term migration.
And here I have one example, because right now it's not possible to do migrations, jumping to a million versions of royal for instance from 1,7 to 1,9, this is not supported.
You need to do the other procedure, the procedure from 1,7 to 0,8, then from 1,8 to 0,9.
Okay, it's a little bit complex.
Also, sometimes it's not, it's a challenge because between major versions, you might have a lot of new features.
And then my look like really different and then this procedure is not possible.
So then for all those cases, is where the talk I'm about, I mean, the tool that I'm about to introduce this applies, okay, for this case, when we need to learn the need of migrating the content.
Okay, so then in the context of 3PA, what does mean that migration refers to, as I said, the process of moving and assisting identity infrastructure.
I'm talking about user groups, roles, host groups, services, configuration, I mean everything from one deployment to another.
So having the proper tool in this career here is really important for administrators who maintains the infrastructure.
A good migration process, tools make the process smoother, faster, more reliable.
Well, as I used to say, good tools helps the work, right?
So, we have that, I mean, 3PA has had a plugin based migration already.
Since the version 2, I think we are in version 4 now, I mean, it was long time ago.
It provided basic way to bring users and groups into 3PA, but it has a lot of limitations.
Especially when considering EPA three-part migrations, one of the major reasons is that it only makes race in users and groups, just that.
And this means that all the other data, I'm talking about the roles, policies, hostways, access controls, all those objects they are completely lost, okay.
Another disadvantage is that the user private groups, they are not preserved, and you know, in some Linux systems,
a user private group is a special group that is automatically created when you are done a user, and this simplifies a lot, the private files, permissions, and stuff like that.
In other distributions, all the Linux, this doesn't exist, and then you need to play with a mask and a play with different masks.
So, this user private group is also lost because the tool is not capable of migrating this information.
So, another disadvantage is that the plugin drums in the server, in the origin, and then if you have a huge deployment with a lot of identity infrastructure,
the client might get disconnected, and then might take to run.
So, this leaves the process of the migration, because it has not dedicated locks as well.
So, it's kind of a unit to figure out by yourself and then try again and try again.
It's really difficult to solve a suit.
And the last one, I think, the syntax errors, yeah, this is not a critical one.
But you might have some kind of garbage in the origin server, and then that will prevent you to complete the migration.
So, you need to go there and fix all the entries and try again.
So, yeah, this is kind of a very big list of disadvantages of the current tool.
So, this is why we decided to start with a run, run the sign, and what we tried is to fix all the play with limitations.
So, this time, we want you to migrate as much as possible, not users and groups only.
So, we're talking about all the schema.
So, this new tool is capable of migrating the whole schema.
All the configuration settings and the database content, which is a lot.
And the tool is, it's available in the user as well as the name of EPAL Migrate.
So, it's kind of an admin tool that runs a standalone, and this time is run in the client side.
In the free piece server where you want to bring all the data.
So, it has the proper man page, health documentation.
If you go through it, you will see that it supports multiple methods, like online offline.
That makes so much of those approaches.
I have another slide for this one.
And also, it supports multiple modes of migration, like production mode or steady mode.
And yeah, this migration process varies depending on the selected mode.
So, I have another slide to talk a lot a little bit on the modes.
So, another cool feature is that it is able to do some kind of sort of write one simulation.
Okay? So, you just that the dust has dried one, and then you will simulate that you are performing the migration.
And you will identify the issues in advance. This is really, really good.
Yeah, and finally, yeah, this time, I mean, the new tool obviously provides the proper login and a summary report at the very end.
So, it makes really easy to travel through fixes, and I'm going to get an additional immediately.
I have a demo as well. So, we will see that in a video that I recorded.
So, yeah, this is like this to tell you what is currently migrated.
It consists of three areas, of major blocks.
So, the first one is the LDAP schema.
So, it is capable of migrating the obvious classes and attributes.
If you have a custom schema in your, your, your, your, your free free server is going to be migrated as well.
So, this is very powerful. And also the configuration is migrated as well.
Including all the performance, tuning, all the security settings, all the log, all the rotation settings.
I mean, everything is fully, fully migrated.
And another important area is the data is.
And as you can see, all the objects are mostly migrated.
The counts, each, what rules to the rules, DNS, curve laws.
Well, there is one particularity is that the passwords, they are, are migrated,
but that the user needs to do an LDAP authentication after that to regenerate the new curve risk credentials.
And this is done automatically when the user is authenticated in SSD.
Or they can simply throw by, if I migrate and point and do the same.
So, yeah, so this is all the objects that are migrated.
So, but also, yeah, what, what is not currently migrated?
I mean, there are some particularities. So, for instance, the replicas are not migrated.
You know, in creepier, you can deploy a server, you can have replicas among the clients.
So, this tooling is just migrating the, whatever is in the server to the new one.
It's not migrating the replicas. So, all the data that is referencing to the objects from the replicas is simply not migrating.
Okay, but anyway, once you complete the process of the migration, you can add more replicas to the server,
and you can run a par replica stall, so that you can establish the topology.
So, it's not a big deal. And the second one, and this might be more problematic is that all the certificates,
I mean, the migration doesn't, that's not bring over the assistance certificate authority.
Instead of that, the new API installation generates its own CI.
And the issue is that you can distinguish between them.
I mean, if you're used in the same pre-al, the certificate is taken on time, domain and CI,
sat yet, and there's no way to distinguish between them. So, it means that all the certificates will need to be reused to re-shoot again in the new server.
Okay, they are toast.
And another one, and the last one is, I think I already mentioned this one, is that the Kerberos keys are not migrating as well.
So, while Kerberos, all the principles and users on services and entities, they are retained,
but the Kerberos master, for instance, the Kerberos master key is not transfer.
And that means that users will reset their password or re-roll services as needed.
So, then, yeah. So, to ensure the flexibility in different migration scenarios,
the tool supports multiple methods. This is what we call methods.
So, the first one is an online migration, okay.
It will involve, it will establish a communication between the target system and the ring system,
and it will do everything over the network.
And, well, if you have a huge deployment with a lot of users, 50k users, more than 500k users,
and a lot of identity infrastructure, that will take time, you know.
So, then we have also the fly mode.
For a situation where, and also for a situation where the network access is not ideal or not possible.
And, well, what you do then is to use the tool to dump into all the files, the three major ideas.
I mean, the configuration, the schema, and the database, you can do that in the region server,
and then you copy the files to the target and use the tool to deploy the materials.
But, this is a little bit tricky. So, in terms of where we need to generate three files.
So, we can do a mix of the other two previous modes online and offline.
So, with the online, maybe you can copy the configuration on the schema that is not big.
It's not usually big, and you can do that with the tool.
And, if you have a very large database, you can use the, the other one, the fly one.
So, this is very flexible.
And, then, we also have multiple modes, migration modes.
These are some sort of templates that are pretty fine.
So, in production mode, we assume that the remote server is fully functional.
You want to migrate from a production environment.
So, we want to perform a full migration while preserving everything.
And, this means that all the DNA, users and groups like this,
secretaries, the fires and other critical identity attributes are migrated the same way.
They are not changed at all.
And, this ensures that the new deployment is to replica of the original is kind of production.
Then, we have another mode, which is the staging mode.
And, that one is used when my rating from my staging or a testing environment.
This is kind of for the family members or for testing.
If you want to migrate from there, you are not, the tool is clever enough.
So, it's not migrating the DNA ranges.
The IDs and the SIDs are directly from there.
Okay. So, instead of that, the attributes,
relative to automation of the ID generation are reset and the special magic values they are at it.
So, this is for preventing conflicts and between staging and production environment.
And, finally, there is another mode, which is the right one.
I already talked about a little bit about this one before.
And, yeah, this is a great way to verify that my Russian process
or check for potential issues.
Confirmed that the right data is made my rate it transfer to the current server.
This is kind of formation, yeah.
So, yeah, this different modes provide flexibility based on the different needs.
It depends always on the context.
And, then, we have also the ability to define something place.
We have to find something place because we can mix those modes.
And, we can do multiple scenarios like my rate from production to production.
In this case, all valid AP entries will be migrated.
All IDs, UID, UID, SID will be migrated.
At the same time, the certificate will be, will be dropped, as I mentioned,
because there is no way to distinguish between the CAs.
And, another scenario, I'm interested to my one-to-do,
is to move from production to an air-stage environment for testing.
And, in this case, it must be a different real.
Okay?
Just to avoid conflicts.
You don't want to mess with your production server.
And, in this case, all the certificates from the previous CAs will be preserved,
because you are not my rating them.
And, yeah.
So, depending on the scenario, you have different particularities.
And, yeah, and the last one is also interesting.
It's from an IPA backup.
And, yeah, this basically restores the IPA system with the same,
exactly the same preamp and the main.
And, this method is ideal for disaster recovery, those sort of things.
So, then.
Yeah.
So, this time, the tool prints the enough logging information.
This is so important, because if the migration stops at some point,
you will see what is the issue instantly.
And, then, you can fix it and then you can retry again.
And, also, we are adoptions like variables in the clear option,
so that you can increase the level of information that is printed out.
So, this kind of was missing in the other tool.
And, yeah, this is another thing that I love is the summary report.
So, at the beginning of the migration, it's everything went okay.
So, you are getting a report like what you see in the right of the screen of the slide.
It's summarizing all the objects that they were migrated,
so that you can realize if something was skipped or from the ring.
So, I think.
Yeah, five minutes.
Yes, I have had demo.
Yeah, the demo.
Well, the demo is pretty much simple, but this other samples,
all you can play with the tool, but let me jump into the demo,
because I don't have too many time.
So, let me see.
This is a video.
So, what you see now is on the left.
The left is the re-inserver.
And on the right, we have the target system.
And those 3P servers, they kind of empty.
They just provision empty, okay.
You can see that is well, they provisioned with the use of the staff from scratch.
But there is no content.
So, what I'm doing now is to log it into one of the server in the re-inserver.
And I'm going to use one of those pathoscrips.
I have for creating data, identity data,
like it creates a lot of users and sort of rules,
HFAC rules, all those sort of things.
But I'm doing now is to set in the server in my re-inserver mode,
so that I can add the users with all that has path works.
And I'm simply adding to the buildup server.
I'm just adding all the data.
I'm sure about it.
I think it's the already kind of some sort of 60 users per group.
What is adding the server rules now.
Now is adding HFAC rules.
So, as you can see, this way of adding content is really slow.
Okay. So, okay.
Now that everything is there, you can see that a lot of 61 users they were added to the server.
If I go to the web UI, I can see them there.
The same for groups, services.
Yeah. So, plenty of identity infrastructure.
So, now I, yeah.
I'm going to use the e-part-mind-break tool on the other console.
So, basically, you can see that this deployment is completely empty.
Yes, I'm setting a server in migration mode, but I think this is not needed because the tool is already capable of doing so.
But it's just in case.
And yeah, this is the command.
It's a migrate production mode from the origin.
And this is first of all, that's the driver.
As you can see, it's super quick, it's super fast.
In terms of seconds, it managed to fetch all the data.
So, yeah, that's the summary.
And now I, say, everything went okay.
I just kind of removed the, that's the right run.
And now we're going to perform the real, the real one.
Yes.
Yeah, I think, because I'm getting out of time, right?
No, I mean, it's supposed to be quick.
Yeah.
Yeah, most of the, yeah, the schema, the confusion and the database was already migrated.
It process more than 800 entries.
And at the very end, it's running the API server upgrade.
This is in, yes, in case there are changes in the, a lot of schema or something.
And then the API server upgrade is taking care of those things.
Yeah, this is supposed to be quick.
Yeah, I can't speed up some seconds.
Yeah.
So, it was completed and then you can see the summary.
And I think it's open by the word, the idea is to see that, yeah, the content is there.
Okay.
So, in terms of minutes.
Yeah.
So, that was the demo.
I think I have more slides.
Let me see.
Next one.
No.
Okay.
Jesus.
Okay.
There's need to grab the screen.
Okay.
Fine.
Okay.
So, yeah.
We have everything automatically.
You can draw by this link.
And you will see that this tutorial about the format rate is available in GitHub.
You click on that.
This is one of the whole process stuff.
We can file stream.
And then you follow some steps and everything can run in your local system using podman containers.
And yeah, this is, I think this is the last slide.
You know, the API migrate tooling is available in the free API provider ready.
As I said, you can find it in federal umbrella.
And yeah, it will be nice if you can try.
You can try any combination.
You can migrate from multiple systems.
Mixing different versions of IPA or the practice system.
And you five issues please draw by our project and draw by ticket there.
And we also did a federal test day as well.
So, you can draw by the link and then see the results.
And yeah, I think that was all.
Yeah.
So is there any question?
I will be testing this tool for couple of weeks.
Because if it doesn't have a nice way to change the CA.
So this is right to migrate to another server and create a new CA.
But unfortunately, for protection environments, all the users have to live all game so well.
If you have many users, you have to ask everybody to log in before you can change to the new server.
Is that it's on the point to migrate everything so the old credentials keep working.
And the user doesn't have to have the password represented and working again.
Yeah, well, I mean, yes, this is an argument.
When you migrate all the users.
Yeah, the users must at least log in the very first time to regenerate the caraberos.
But this is automatically done.
As soon as the user is logging into SSD, it's done.
No, the password will work, but the user just must authenticate so that more content is regenerated.
So the key is to keep your new system, new deployment in migration mode.
Then SSD will notice it.
And when the user tries to log in, it will automatically try to help bind with whatever user provided.
And that help bind against IPS server will generate caraberos keys.
For the user, the actual experience will be exactly the same.
They don't need to go anywhere else. They just need to log in.
Yeah, automatically.
It's only done if you're in migration mode.
That's quite important to set.
This tool should be set in migration mode by default.
Or instructions are saying enable migration modes.
So this config mode, there's there's migration something.
The other solution is switch from password to passwordless methods.
Then they don't need to have any caraberos keys themselves at all.
And during migration, nothing need to be generated.
Yeah.
Like external IDP use, for example.
This information will be migrated.
There are no keys, caraberos keys.
Also, they don't need to be replaced.
Same way of the FIDO tool can spur some.
Yep.
So when any other question,
All right, good.
Thank you.