
vir8k (vir8k) asked a question.
We master with Ultipro, user is created in Okta, then attempts to create the user in AD. It can do so but the manager field can only be populated with a blank as AD is expecting the full DN.
I cannot seem to come up with a solution and was wondering how others are solving for this. I am assuming we aren't the only people who want/need this attribute to be populated in the expected format. This field "managerDN" is used upstream for Office365 and other systems.

Hey Josh,
Do you have a field, for Okta Active Directory, managerUPN? We had this problem but found that populate this managerUPN field allowed us to set manager for users.
It allows us to pass <manager>@domain.com in the field to map a user's manager.
If you have multiple domains in your organization, it may require a little bit more thought. We have a workaround solution at our company for multiple domains, but it's not perfect so I'll refrain from suggesting it. But should be something to consider for growth.
I hope this information helps!
Thanks for the response. I have mapped that value now using the okta user.manager snytax. I don't believe this will solve our scenario but I want to see what attribute it will populate. With Office365 upstream it seems pretty dead set on requiring a managerDN attribute to be populated with the full DN (cn=user,ou=xxxxx,dc=xxxx.....) like that. Not sure how to get around that.
Does your office/azuread instance show managers? If so how are you populating those fields?
Hey Josh, O365 does show manager for us as well. We Federated O365 with Okta. We found out the hard way that you need to make sure to have Universal Sync option enabled for your "Sync type" in the setup. Once that was enabled for us, all the attributes mapped automatically based off AD. So for example our manager field populated with:
hasDirectoryUser()?findDirectoryUser().managerDn:null
So it's based off our AD sync to Okta.
If I am not mistaken that attribute set would only pull from existing AD attributes that were placed there by something else or pre-existing. What are you using to populate that? Are you doing it manually?
I did something in a past life with WD where the attribute was pushed from WD to Okta and then Okta to AD using the email address for the manager. Since i'm no longer with that employer I can't provide the screenshots but I recall it working well.
I'm facing this same problem currently. I'm kinda shocked that there isn't a cheat sheet type solution easily found with a search.
My scenario - much like the OP is that HR uses Okta API's to create a user in Okta. They manager's employee number, and manager ID is available at create time. HR has / uses that information, and populates Okta UD with the value. AD is a different story. The actual AD [LDAP] attribute calls for a DN syntax, which means it has to resolve to a user in the AD domain. The only possible way to do this is to take one of the values that HR has / passes to Okta UD, like manager employee number, search for that user via LDAP, read the DN value of that user object, and write it to the manager attribute on the user object I'm synching to AD from Okta. TTBOMK, there is no library / utility / expression native to Okta to perform this function. There has to be a way around this.... -- right?
I found some old screenshots on how I set it up (this was ~ 4 years ago):
* Map the WD managerID attribute to the managerID Okta attribute
* Map the WD managerUserName attribute to the managaer Okta attribute
* For Okta to AD, use a custom expression to user.manager (the okta attribute) to the AD managerUPN attribute: ex: user.manager + "@yourdomain.com"
I hope this helps - I can provide screenshots if needed.