Installing a fresh Windchill System with Azure AD as the (only) user directory?

[GaryMansell]

Hi,

I think as of Windchill 12.0.2 it is possible to use Azure AD / Entra ID as the store for all Windchill user accounts (including Administrator) - is that correct?

I believe this entails:

1. Setting up an Azure AD / Entra ID Enterprise Application for Windchill
2. Setting up a Shibboleth SP Server to deal with the SAML requests from Azure AD / Entra ID and configuring Apache to talk to it.
3. Configure Windchill with properties for the Azure AD Enterprise Application settings and Shibboleth SP 

Is it possible to set this up for a fresh install of 13.x using the default PSI installer setup screens, or do you need to do an LDAP v3 compliant install first to (for example WindchillDS) and then re-configure it (post install) to then switch to Azure AD / Entra ID authentication?

One thing that has confused me is the PTC doco on the subject mentioning the need for an LDAPS connection - as Azure AD / Entra ID does not support LDAPS. Does that mean that to use Azure AD / Entra ID, you have to setup Azure AD Domain Services too - and this acts as an LDAPS server intermediary between Windchill and Azure AD / Entra ID (which makes little sense to me as Azure AD / Entra ID auth would use SAML)? 

Is anyone able to clarify my understanding of this, as I want to test building a simple OOTB Windchill 13.x System with Azure AD / Entra ID authentication and am not quite sure how to start?

[jbailey]

You can install Windchill with just access to AD (wherever it sits). You will need an admin account similar to wcadmin but in your enterprise active directory. As for Shibboleth / configuring SAML, that shouldn't be a problem either. That being said, Windchill will still need to talk to need to talk on the ldap protocol (ldaps should be used). Infoengine makes ldap calls to do queries (group to org mapping, user search, group search etc). If you want to purely use Entra, I believe you would need to have access to Microsoft Entra Domain Services (Havent done Entra before, but your Azure folks should be able to verify this) - which allows ldap calls (https://learn.microsoft.com/en-us/entra/identity/domain-services/overview).

As to your steps:

1) Yes

2) Kind of - Shibboleth SP isn't a separate server, it is installed on your application server and through the apache configuration redirects apache auth requests to Shibboleth to complete the SAML auth. 

3) Yes but... (See my note about Entra DS)

You can do a fresh install of Windchill 13 pointing only to some AD tool (no Windchill DS needed), however See my note about Entra DS (Installation will need to access the admin user that exists in Entra via LDAP/LDAPs call)

[GaryMansell]

@jbailey - that's super useful information, thank you very much - if only the PTC Support site could be clearer.

I have read loads of PTC docs and they suggest that you can use Azure AD / Entra ID for Windchill Auth, and no where does it clearly state that you can only use Azure AD / Entra ID Auth if you _also_ configure Azure AD DS in your Azure environment to do the LDAPS Auth that InfoEngine needs.

It's no small task to also setup an Azure AD DS server in your Azure environment that Syncs with Azure AD / Entra ID. Also for modern Authentication - it would be good to be able to leave AD / LDAPS behind and only use (Internet-based) SAML / OpenID Connect / OAuth type authentication solutions.

I was hoping to setup an isolated network/environment in Azure with a small Windchill environment that just did Azure AD / Entra ID Auth - but it looks like this is a non-starter 😞

Does anyone (from PTC?) know if there are any plans for Windchill to solely Authenticate against Azure AD / Entra ID (and ideally) out-of-the-box (ie be able to set it up simply at install time via the PSI?)

Regards

Gary

[jbailey · Accepted solution]

https://www.ptc.com/en/support/article/cs349038

• AzureAD itself cannot be used as a LDAP server
• Azure Active Directory Domain Services (AADDS) needs to be configured which provides a LDAP server (Now Entra Domain Services)
• Refer to section Entering Your LDAP Settings in the PTC Identity and Access Management Help Center

I agree on the difficulty.

I approached some folks at PTC last year at Liveworx to get interest of an authentication/authorization working group/tech committee... Windchill has a ways to go in modernization in that area.

It was brought with a warm reception, but nothing has come out of it yet.

Jim

[GaryMansell]

Ah thanks (again) - I get it now...

Azure AD / Entra ID (on it's own) _CAN_ be used as the Identity Provider (Authn & Authz) for Windchill users.

But... Windchill _ALSO_ needs a separate LDAP Server for other (non IDP) data & configuration storage.

Hence, even if you do use Azure AD / Entra ID - you will still need a separate LDAP server (whether this be WindchillDS, OpenDJ, OpenLDAP, AD or AAD DS) .

Got it - thanks for the clarification, and all the best to you.

Gary

[jbailey]

Correct. Sort of. Entra _CAN_ provide Authz but only in the context of access to the application itself. There is no intelligence beyond Windchill getting the username from the IdP and then using the username, role, and policies (and maybe security labels) to determine access...

And that's my heartburn here as well, because Windchill still relies on Ldap v3 calls on the back end, it makes it difficult to deploy a modern, cloud instance of Windchill - especially if you are federating users from other organizations.

Another difficulty (if you take it a step deeper with security labels / restricting access) is bringing more information about a user into Windchill so you can write simple expressions / code to evaluate access. If your company has AD attributes that tell you about someone and how they should be able to access data (like citizenship, organization, security clearance etc) you have to customize Windchill to bring those additional attributes over. So you are pretty much stuck with pulling people from AD groups to populate groups, or writing custom functions (in the case of security labels) to inefficiently make calls to other systems on the fly to see about that person.