ScottC.38230 (Customer) asked a question.
I have a non-Okta problem I'm hoping I can make into an Okta solution.
Our in-house infrastructure was built using SFU/IDMU so our users all have rfc2307 uid/gid/etc attributes.
In Redmond's infinite wisdom, they killed of IDMU years ago (Server 2016 was the last system you could bolt it onto and even that wasn't great) and their "solution" is to hand assign uid/gid to users in LDAP.
Since we want to retire our older AD servers, I've been looking for a reasonable solution for this problem.
It occured to me that I might be able to use Okta, either just the Expression Language or a workflow, to assign values to users w/o these attributes. I honestly have no idea if it would work of I'm crazy (or, quite possibly both), but I was hoping to find out.
In a pseudo code it might look something like this:
newuids=10000 *a start that has several hundred open uids since windows assigned them seemingly randomly
defaultgid=100
On import from AD:
Map uid to "if exists, do nothing, else assign newuids, increment newuid by 1"
Map gid to "if exists, do nothing, else gid = defaultgid"
Map shell and home path as well
My hope is that if Okta updates these on import, then will they (or can they) be exported back to AD automatically?
So if a user comes in with existing uid/gid they stay the same, if they come in without, they are assigned both and then those values are returned to AD.
Again, I'm not sure if this is possible, and I am looking into ASA but I don't think it's on my current paid plan so sticking with AD as LDAP locally is my current preferred solution.
Thanks!
@ScottC.38230 (Customer) - I would say this one falls in the realm of "Maybe". Assuming the property is one you can filter against while "Listing users with Search" & the total number of users that needs to be updated isn't something massive (10's or 100's of thousands) this portion should be relatively trivial to build out in Workflows. The attribute would need to be Okta Sourced (Meaning it can be changed inside of Okta).
You could do something as simple as storing the ID in a table and updating that table after each successful user update. So basically Read table, Increment, Update User, Update table.
The part I don't know is if you could synchronize this data back to AD. It should be easy enough for you to test by just manually adjusting a test user and seeing if you can get the end-result you are looking for by manually updating the property in the user profile.
Thanks, I have some homework to do. I've done some simple string transforms like create a custom field on the way in from AD that another needs for the username, but this is an order harder for sure. Thanks for the tips on where to start.