Disable user accounts from Windchill

[sconroy(custome]

When you select Editing User on the Set Attributes tab it would be very useful to have a check box to Disable Account or be able to right click from Participant Administration on the user and disable account. I know it is possible from a Windchill Shell but this is not accessible to all Admins of Windchill and therefore not possible

[Devidas]

Can you explain how to disable the user account using Windchill shell?

It will be nice if PTC adds this functionality in UI.

[sconroy(custome]

Hi Devidas

if you use the following command in a shell from the WindchillDS/server/bin folder...

manage-account -h localhost -p 4444 -D "cn=Manager" -w "password" -X set-account-is-disabled --operationValue true --targetDN "uid=userid,cn=Windchill_10.1,o=ptc"

will disable the account.

Thanks

Shaun

[doehr]

I wonder if this is necessary. If you're a Site Administrator and need to lock down someone's account can't you just change their password from the Participant Administration function? And at the same time alter their display name with some kind of tag to show that the account is disabled, so managers of the context team(s) that they belong to can quickly see the disabled account and replace them?

[sconroy(custome]

Hi Daryl

Yes this is an option, but still would not stop a lucky hacker from being able to access your system and the files with a correct combination.

Thanks

Shaun

[doehr]

Unfortunately that argument could be made for active accounts as well, if anyone did try to hack accounts and knew a little about how PDM worked they would go for one of the administrator accounts to get the most access. You need good firewalls to really stop that.

[LewisLawrence]

For us there are two reasons why we would really like this functionality.

1. We maintain user accounts based on activity, so if someone has not logged in in more than X days we disable their account.
2. If someone changes roles in the organisation and doesn’t require access.

In both cases we want to disable the account and prevent them using the application, but maintain the access/permissions the account has. So the account can easily be resurrected if required without any additional modifications to re-instate access.

[doehr]

Well, there are ways to do that depending on how you have your accounts set up. I would suggest for disabling an account, not only change the password but also edit one key aspect of the account setup that hamstrings the access but it is very, very fast to restore. If, for example, you base most of your access at the Org level and give every standard user one key Profile, remove the Org and Profile which takes only a few seconds. That way even if someone did hack the account through your new password they wouldn't be able to do much at all, but once the person has to come back you can restore it in under a minute. Plus changing the user display name (perhaps putting Deactivated_ in front of their name) so that people can see it's a disabled account on the context teams.

Just trying to give ideas of what you could do now that does (what I think is) everything you need.

[LewisLawrence]

We use integration to a corporate Active Directory to control authentication at the web server, Windchill permissions are managed using role memberships in context teams. We use distributed administration with “team administrators” who work in the business in control of who has what access to their data. Re-creating users if they get deleted takes a lot of effort. Currently we have a clunky process similar to some of what you describe to de-activate users when needed, it takes a lot of time to manage and is far from ideal. We average around 120 users per month who come and go.

This idea has been discussed to death at various technical committee meetings for years, usually as a side subject around the related and much thornier topic of how Windchill licensing “works”. As the workarounds prove, this is a nasty gap in the application. Being able to temporarily disable an account as a stop gap instead of deleting it is very desirable to Weatherford and a number of other customers.

[BjoernRueegg]

With a AD interface you also can check if the user is disabled in the AD or you can check if the user is member of a Windchill Access group. If he's a member i can login if not he won't be able to login.

I know this is not a solution you're looking for. Just another workaround.

[BenPerry]

Bjoern Rueegg‌,

We might want to deactivate the employee's Windchill account ... but in AD, the employee is still an active worker.  So they're not disabled.  They just haven't used Windchill in a while.

Just another use case to keep in mind.  Can't necessarily use the disabled flag in AD to cover all Windchill users that need to be disabled.

[BjoernRueegg]

Ben Perry‌

If you use a group in the AD and check the login if the user is a member of that, you could remove the user from the group and then he won't be able to login to Windchill anymore. So the AD user is still active and the good thing is, you have the overview and you can control the active Windchill user.

[BenPerry]

In that case, will the Windchill user become disconnected?  I can't remember.

I think they will still be connected - they just can't log in anymore.  So maybe the user still appears "active" and shows up in the UI - and other users can select them in certain pickers.  But the user can't actually log in.

But if I'm wrong, and the user becomes disconnected, then that would solve that problem.  But my experience is that the AD user only becomes disconnected if they are actually moved around in AD.

[BjoernRueegg]

I belief the user is being disconnected but I'm not 100% sure anymore.

If you move the users, they won't be disconnected anymore. I think there was a fix in WC10.1M040 to solve this issue.

[TomU]

Yes, if a user is not visible in the LDAP (Active Directory group in this case), then they will show up as disconnected.  Once disconnected they will not be visible in Windchill (to other users) until their account is either reconnected or deleted.

Adding and removing users to different groups in Active Directory isn't a problem, but physically moving their account to a different location is because it changes their distinguished name.  You would have to manually fix their account if this happens.  (This may be changed in later releases...)