Restrict Users during Windchill 13 Upgrade

[Dannerj]

Version: Windchill 13.0

Use Case: During the Windchill upgrade, we want to restrict the general user base from accessing the Windchill UI to prevent any unwanted changes.

Description:

We are upgrading to Windchill 13, and now that we are using Active Directory with Single Sign on, I am wondering what others are doing to restrict access to the UI to only an Admin group during the upgrade process?

We are already filtering AD with a specific group to provide access to Windchill.
Is it possible to add an additional filter without causing all the users to become disconnected?

The only solution PTC had to offer was restricting UI access to only the server on which Windchill is installed.  This will hamper our upgrade as we would only be able to have one Admin at a time logged into the UI to perform specific activities, and we would need to hold off on any of our accounts that connect to 3rd party apps until the end.

Looking for alternate ideas if possible.  I have to imaging this is a common problem that you would want to block users from accessing the system during an upgrade.

[mmeadows-3]

There are several ways to do this.  Here is one article.

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

[Dannerj]

I like this option in theory, but I could not get it to work with Windchill 13.

[mmeadows-3]

I'm assuming this is actually for post-upgrade validation testing.  That can be handled through the Apache configuration.

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

%wt_home%\..\HTTP Server\conf\app-Windchill-authProvider.conf

Don't disable any JNDI Adapters in Windchill as that can break the upgrade.  Just filter them out of Apache.  Apply an LDAP filter that excludes all but a specific users (e.g. "sAMAccountName=wcadmin") or a specific LDAP group (e.g. "cn=Windchill Validation Team").  That should block access to everyone else prior to SSO validation.

Some examples...

OpenDJ/WindchillDS

<ldapUrl>ldap://ptc-training.ptc.com:389/ou=people,cn=AdministrativeLdap,cn=Windchill_11.0,o=ptc???(|(uid=wcadmin)(uid=orgadmin))</ldapUrl>

Active Directory

<ldapUrl>ldap://ads.ptc.com:3268/DC=ptc,DC=com?sAMAccountName?sub?(&amp;(objectClass=user)(|(sAMAccountName=mjones)(sAMAccountName=kfry)))</ldapUrl>

Notes:

• Syntax for OpenDJ/WindchillDS assumes unique ID is "uid" and subdomain search "sub".  So, syntax is: ???(uid=wcadmin)
• Syntax for Active Directory: ?{sAMAccountName | UserPrincipalName}?{base | sub}?uid=wcadmin

For a filter group, call out a group from the LDAP that includes the validation team members.

<ldapUrl>ldap://training.acme.com:389/ou=people,cn=EnterpriseLdap,cn=Windchill_11.2,o=ptc??sub?(isMemberOf=cn=Windchill%20Validation%20Team,ou=people,cn=AdministrativeLdap,cn=Windchill_11.0,o=ptc)</ldapUrl>

The configuration really depends on how many JNDI Adapters you have. There should be a way to block everyone except the default Site Administrator (required for Windchill to start) and any defined group of validation users coming from the corporate LDAP.

One way to validate LDAP Search criteria outside of the adapter is to use ldapsearch (part of OpenDJ and WindchillDS)…

%wt_home%\..\WindchillDS\server\bat\ldapsearch --hostname {LDAP server hostname} --port {3268 or 3269} --bindDN "{user’s DN}" --bindPassword {password} --baseDN "{search base}" --searchScope {base | sub} "(sAMAccountName={username} or userPrincipalName={username})"

For example, AD LDAP search criteria to find one user in subtree:

%wt_home%\..\WindchillDS\server\bat\ldapsearch --hostname ads.ptc.com --port 3268 --bindDN "CN=Windchill Bind User,OU=Services,DC=ptc,DC=com" --bindPassword {password} --baseDN "DC=ptc,DC=com" --searchScope sub "(sAMAccountName=mjones)"

Propagate changes:

ant -f webAppConfig.xml regenWebAppConf -DappName=Windchill

Restart Apache

Maybe this helps?

[Dannerj]

Not sure if it's just our configuration, or how different Apache is with Windchill 13, but I could not get this to work either.  I added a reply below with the solution I'm currently exploring.  The solution below works for our application, but could use further tweaking to enable it to work with Single Sign On.

[avillanueva]

Typically upgrades involve a new target system and a new IP. You can not broadcast the DNS mapping to your target to the masses but only to those admins who need to participate during the upgrade. I assume that you are doing rehearsals with a different temp hostname. This would allow changes to be done to the system and validated before replacing source with target for real. In my last final go live, the last thing we do is update DNS entry for the hostname people know to bring the system back online. 

[Dannerj · Accepted solution]

One thing I'm learning is that Apache 2.4 (Windchill 13 vers) is very different from previous versions.

I appreciate everyone who has commented thus far.

I ended up merging a couple of ideas from CS61527 and CS236329 and created a 99-app-Windchill-Auth.conf file in the conf.d folder, with the following information, and restarted Apache:

# Authenticated resources

<LocationMatch ^/+Windchill/+(;.*)?>
AuthName "Windchill"
AuthType Basic
AuthBasicProvider Windchill-corporateLDAP
Require user userID1 userID2 UserID3
</LocationMatch>

<LocationMatch ^/+Windchill/+infoengine/+verifyCredentials.html(;.*)?>
AuthName "Windchill"
AuthType Basic
AuthBasicProvider Windchill-corporateLDAP
Require user userID1 userID2 UserID3
</LocationMatch>

<LocationMatch ^/+Windchill/+protocolAuth(;.*)?>
AuthName "Windchill"
AuthType Basic
AuthBasicProvider Windchill-corporateLDAP
Require user userID1 userID2 UserID3
</LocationMatch>

This appears to work, however utilizes Basic Authentication (requiring User input for Username and password).  I'd prefer if it worked with Single Sign On, but I can't seem to get that figured out quite yet.  I did try changing the AuthType to shibboleth, and I tried removing AuthType all together, but neither option worked.