Workfront / Active Directory integration

[SkyeHa]

Did anyone integrate Workfront with Active Directory and have anything they can share? I'm looking for something that takes the load off requiring someone to tell me when there's been a user change, so basically as users get job title or manager changes in AD, this triggers a change in WF and if they get deactivated in AD, it will trigger a request for deactivation in WF. Also wondering how you got approval from your AD admins. :) Thank you! -skye

[GregTr1]

Hey @Skye Hansen , we use Azure Active Directory for Workfront authentication. We don't pull over manager-team relationships right now, so I can't speak to that. We do pull over Cost Center so we can easily charge CapEx and non-CapEx time to the proper accounts for each team - we insert that into the Address2 field, since we don't need that field for anything else and it's not visible to users on the standard profile view. Just thinking about the Manager field, I would ask Workfront what they want to be inserted there - email? I believe that email is the primary key for Workfront users. If so, you may have to work with your AD people to create a new field in the feed (i.e. lookup a users's manager and pull in that manager's email address) if that's not already available. Then it's just simply naming the proper field in the attribute mapping section of SSO setup in Workfront. Depending on how "hands-off" you want the credentialing and user setup process to be, this can get pretty in-depth and complex - you may end up having to create several fields in the AD feed with your IT team and work with them on establishing the logic required on their end. As you're probably already aware, if you don't map a field, then it can be changed at any time and won't be overwritten by AD. Changes in AD are queried upon login to Workfront, so as long as you have something like a 24-hour auto-logout enabled in Workfront, you should be good to go on Workfront picking up manager, title, etc. changes in a timely fashion without any manual logout/login. As for how we got permission for this... when I joined the company, we already had SSO enabled and the only thing I had to mess with was asking for the cost center field to be made visible in the AD feed for me to map in Workfront. The big arguement in favor of using AD for Workfront login is that you probably can only use your SSO services if you're in the company network, right? So you're either VPN'd in or you're on a secure network in the office - all of that is more secure than using a standard login. Hope that helps answer some questions? Greg Troester, CSM CHG Healthcare

[SkyeHa]

thanks Greg! At the moment we're trying for a Fusion integration with AD to bring a few more fields from AD to map to custom fields in Workfront. The sticking point is that the permissions appear to go both ways (so from a fusion perspective it would be easy[??] for me to make a change to AD, which infosec would obviously frown on). I will bring this info back to my engineer and maybe we can shed some light on something. Thanks so much for taking the time to share how your folks do things! -skye

[GregTr1]

Ah! Got it. I can see how that would be an issue! Do you have Fusion already? We are only using the native SSO field mapping in Workfront Setup - so no two-way interaction there. I don't know, but I think that you would be able to set up an event so that it is triggered upon a user's AD info being changed, but not the other way around. Kind of the same way that events work for tasks and other items in FLO construction. So, for example, the logic would be: Set up AD for standard user credentialing and attribute mapping (if not already doing so) Event = AD Users profile information updated (this could be instant, polled on a regular basis, or you could set up the event to auotmatically run every X-amount of hours/days/etc.) Continue If: a user exists in Workfront (if not, stop) - I would try to add this in so that you don't have a bunch of failed events due to not everyone in the AD user list having a Workfront profile Read Record = AD User Profile attributes you want mapped Update Record = Workfront User Profile attributes This way, if a user's record is updated in AD, it updates in Workfront. Since the event is only triggered by changes in AD, if you were to update a user record in Workfront and overwrite a custom field that is part of the above mapping, the next time the FLO runs the AD info would overwrite any changes. No changes would come back to AD - it is the source of truth in this case. No security issues there, as far as I can see. Greg Troester, CSM CHG Healthcare

[MaddyMa]

I'm late to the discussion, but this is exactly what our IT team is setting up for our instance. They're looking into building a custom API that will constantly communicate back and forth between AD and Workfront. It's not complete yet, but if you want I can let you know what the final result is, Skye. You may already be past this obstacle, but I wanted to share just in case it was still an issue. Maddy Martin Fairway Independent Mortgage Corporation

[SkyeHa]

hi! Yes, we're past this obstacle. We had Fusion and we were having issues with getting permission from IT to connect to AD, because the AD card in Fusion was a 2-way write (would allow us to write to AD). We had Workfront change the card to a read-only so that we can confirm to IT that we will not (and cannot) overwrite AD records. -skye