Hello Folks,
With functions like getManagerUser not working when there are accounts for same okta user in multiple active directories, what is the best way to get the manager attributes.
There are forums where they specify to use expression language to derive the attributes like email from the dn itself using appuser.managerdn and then re-create the email value,
But in our case dn’s are not properly structured to be able to create such expressions… neither is there any clarification from okta on how to get the okta object from this expressions to get other not email like values.
Has anyone figured out a better way to deal with multiple active directories and okta epxression language… please assist.
I am having trouble understanding your problem. The manager DN is stored in the AD profile; if there are multiple AD profiles I would expect getManagerUser to use the profile source priority to identify the DN to use. The second step in getManagerUser is not to go to AD, but to look for an Okta profile that has an AD profile with an externalId that matches the manager DN. So if that user was imported you should get results, if the manager was not imported then a match is not found. Perhaps that is the actual problem? FYI, I haven’t actually built a test with multiple directories, it is just based on years of experience of what I would expect.
Beyond this if you want to use the DN yourself in script you will need to specify which AD instance for the profile in the form appuser.{instanceName}.{attribute}. I am assuming these expressions are someplace where we can pick a profile and not in the profile mapping where you are already locked into an instance.
What I don’t understand is how your DNs are constructed that you cannot use them. It would be really hard that the DN was not structured like CN,OU,DC,DC. Can you give an example of where you are having a problem?
thanks for response @jmussman it is actually documented in okta expression language documentation that getManagerUser is not supported for multiple active directories. The solution to this provided by okta to base your attributes off the dn is problematic as it assumes DN is structured at customers. Our active directory is very old and in due times we have modified the dn formats for example for some user the dn is like CN=LastName, FirstName,ou=domain…. for other type of users the dn is like CN=FirstCharFirstName.LastName,ou=domian… and in still other type of users the dn is like CN=employeeID,ou=domain…. These are just few of the types and there are vastly even formats we have to deal with within same active directory domain, Dont ask my why that is. This is due to lot of historical corporate merging, contractor and vendors conventions that predates okta.
Gotcha, my bad. I thought it did work but I don’t remember every page 
(I contract to Okta Education Services and teach the programming courses, I try to help here when nobody picks up a question)
I am going to assume that managers could potentially cross the AD boundaries. Also, I am going to assume that the manager attribute does have the correct DN in your specification
You need to consider what is the source of truth for the managerDN. I would suggest that you go by the profile source priority and use one of the profiles. But you can query each integration separately.
I don’t know in what context you are trying to do the search. In the API directly you should be able to pull a specific AD profile for a user with: https://{OKTA_DOMAIN}/api/v1/apps/{AD_APP_ID}/users/{USER_ID}
The documentation for that is here: Application Users
Then you can pull the managerDN from the profile data that you get back. BTW, you can also search for the manager with the DN in each AD integration use the API. BTW, Gemini or ChatGPT gives reasonable code for this.
Let me know if this helped, or give me more details if it doesn’t about what context you are trying to do this in.