[URGENT] AD-users not able to login, reseller-support home.

[Andy_Admin]

Version: Windchill 12.0

Use Case: The AD-users cannot login to Windchill. In my country, the support from the resellers is not available anymore. --> I'm desperate. Is there any checklist I can try? Thanks!

Edit: 
When I open the participant administration as wcadmin and click the plus, I get the message:

Page could not respond: /ptc1/principalpicker/principalPickerCD_step

javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09044A, comment: AcceptSecurityContext error, data 52e, v3839]

--> Any ideas?

[TomU]

Check the AD user account that Windchill uses to talk to AD.  Is the account locked?  Has the password changed?  Is the AD server available?  The connection information can be seen in the Apache "app-Windchill-AuthProvider.xml" file.  (See ..\PTC\Windchill_12.0\HTTPServer\conf\ )

[avillanueva]

@TomU indicated a good starting point. I know the state you are in, been there. That file is where the connection is. 52e related to this page:

https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0012749

52e	invalid credentials

Its either the user's credentials are not correct or the user you are looking up AD with is not correct. I would inquire with your IT staff to see if there were any mass changes with AD. Verify that the user who are you are connected to AD with is a non-person and password is set to never expire (or you manually rotate it). Verify that the credentials for it are correct. If you have to change the password, you can update that file that Tom mentioned and restart Apache.

[Andy_Admin · Accepted solution]

Thanks for the responses. I want to share my story, maybe somebody can learn from it:

In the end, I created a PTC ticket (system down, maximum impact, very short description) and they contacted me after an hour. (E-Mail said max.2 hours,)

They provided me with two links. The first one was to find the real reason and to confirm the LDAP error code 49 :

https://www.ptc.com/en/support/article/CS350915 Usage of BT LDAP Browser Client in Windchill PDMLink

There, you got to the folder: D:\ptc\Windchill_12.0\HTTPServer\conf

In the file app-Windchill-AuthProvider.xml you find the ncessary info to get that running. 
After trying to connect, we got the same error (49) and therefore, PTC said, the password of that account in that xml-file was maybe changed.
If that would have happened, you need to follow the procedure in the following case to make it work again:

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

Luckily, it was just some admin that moved the account of the xml-file into some other folder. This then made it impossible for Windchill to get the login info, which resulted in this error. 
After moving it back to the folder (see the xml-file) where it was, everything was working instantly, users could log in again. No restart of anything necessary.

[avillanueva]

To be clear, did they move the account to a different domain in Active Directory? Or was is that the Apache conf file was removed? Very glad you got it working. These are some frustrating issues since its hard to tell immediately what's going on. Make sure this is documented and communicated internally and reminder on system backups. Ensure that admins understand how these applications work and what are the key connections that make them function.

[Andy_Admin]

No, same domain, just moved to the parent folder. (I hope these folders are not called domains. The things I mean are displayed as folders like you have in Windows, you group up users to get them the same access policies and they can have sub- and sub- and sub-folders.)
Nothing (also not the Apache conf file) was removed. So simple, so destructive. (I'm no IT-guy, forgive me my non-IT-language, I'm talking about stuff that I do not know.)

[avillanueva]

Typically, the LDAP definition in Apache requires a user to do the lookup when another user logs in:

AuthLDAPBindDN "CN=<someuser>,OU=Service_Accounts,OU=<some branch>,DC=<your company>,DC=<domain>"

Each comma separated block above is like a folder if you were looking at AD or an LDAP browser. It needs to exactly match to where that user is. If they moved it in AD, that would cause the issue you saw. I might suggest hooking 240 volts directly directly to your admin's keyboard to prevent the next occurrence. 😉 😁

[Andy_Admin]

😉
So, just to make it very clear: The user was in a "parent" OU, so not "Service_Accounts", but in "<some branch>". 

For all new guys, you can read that line
AuthLDAPBindDN "CN=<someuser>,OU=Service_Accounts,OU=<some branch>,DC=<your company>,DC=<domain>"
as an address (read it backwards) like
C:\Windows\System32\Microsoft
just for users, not for files.