How does your company do a user audit in Windchill?

[pcnelson]

What I thought would be a simple task just isn’t turning out to be so. I want to verify that all my active users are in the appropriate active groups, and that all my obsolete users have been moved to obsolete groups. My naïve hope was to run a report showing all users and the groups to which they belonged. I’d even settle for a report of all the different user groups and their members, export that report, and manually sort it to remove duplicates, but neither option seems to be possible. I am on my 5^th report from tech support and since they can’t seem to figure it out I am losing hope. Is there a solution to what I need to do, or does everyone just let their user list grow to infinity and hope for the best? We are on 10.0 M020

[kiljaedenas]

Hi there,

Are you sure you don't have those kinds of reports already? We have several that I believe were already in place when our PDM solution was first installed, but several of the good ones are a bit buried in the utilities menus that only Administrators can access. What is your access level in your system?

Daryl Oehr

Engineering Systems Analyst

Westport

Vancouver, BC

Canada

[MikeLockwood]

We have the same need - formalized by corporate recently to require:


· At least every 6 months verify:

1. Accounts for all users who have left the company are disabled / non-functional

2. All remaining users have appropriate permissions (for us this means appropriate Group membership, which has to be ok'd by their supervisor)

3. Identify any users who have not logged on for at least 90 days and request that they confirm need to continue having an account

#2 above is the main challenge. It requires:

- Concise "cheat sheet" in user language for how permissions are applied (a user in this group can do xxx and cannot do yyy)

- Routing a verification of some type to each user's supervisor (Windchill does not "know" who each user's supervisor is, so this is outside Windchill)

In our case we apply permissions strictly using Groups. There is no OTB report for listing the members of each Group (unbelievable!!). We paid a consultant to create such a report - run from a Windchill shell.

Haven't yet worked out an elegant way to do this twice a year.

[kiljaedenas]

In Reply to Mike Lockwood:

We have the same need - formalized by corporate recently to require:


· At least every 6 months verify:

1. Accounts for all users who have left the company are disabled / non-functional

2. All remaining users have appropriate permissions (for us this means appropriate Group membership, which has to be ok'd by their supervisor)

3. Identify any users who have not logged on for at least 90 days and request that they confirm need to continue having an account

#2 above is the main challenge. It requires:

- Concise "cheat sheet" in user language for how permissions are applied (a user in this group can do xxx and cannot do yyy)

- Routing a verification of some type to each user's supervisor (Windchill does not "know" who each user's supervisor is, so this is outside Windchill)

In our case we apply permissions strictly using Groups. There is no OTB report for listing the members of each Group (unbelievable!!). We paid a consultant to create such a report - run from a Windchill shell.

Haven't yet worked out an elegant way to do this twice a year.

[MikeLockwood]

Membership in context teams could also be very important depending on how you set things up.

For us, we use context team membership only for routing workflow tasks, not for user permissions - and the vast majority of these are done thru org-level team templates. We have good reports on the team templates so they are easy.

[kiljaedenas]

Ah, that's a bit different than what we do, we tie our access levels/permissions based off of the context team roles, as we have quite a few product line contexts with different engineer groups working on them so we can't really put a full user group in most of the key roles. That would make a mess of our engineering changes. We do havea small handful ofuser groups but they're primarily for general auditing, read-only Guest access and a couple of groups for the designer "grunts" that do the main CAD work, often co-op students that we cycle through regularly. Sounds like I may not be able to help you very much.

In Reply to Mike Lockwood:

Membership in context teams could also be very important depending on how you set things up.

For us, we use context team membership only for routing workflow tasks, not for user permissions - and the vast majority of these are done thru org-level team templates. We have good reports on the team templates so they are easy.

[bellj]

We have similar needs.
We apply all permissions to context roles and try to put only Groups in Roles.

We solved the Group Membership reporting issue by creating a function in Oracle that iteratively queries the WindchillDS LDAP and returns groups and members.
I then use (dozens) of Excel sheets to query those Groups and Users and everything else like ACLs, Libraries, Types, States, Roles, PrimaryBusinessObjects, Processes, Assignments, Lifecycles, Workflows, etc.

It's not pretty and requires constant maintenance and manipulation but it works.

joe bell
GSIMS Administrator
GPS Sustainment Information Management System
719-572-2890
bellj@gpssims.com<">mailto:bellj@gpssims.com>

[pcnelson]

I did not find a simple solution. I'll ask the question I think others probably have, but may not want to ask publically given that PTC does take part in the forums. If it is so difficult to get the data to manage our licenses, can PTC evendo it? My intent was to audit the number of active users and match that numberagainst our number of licenses. It appears others have this same issue. I have “x” total users. I have “y” users in active groups and “z” users in obsolete groups, and x = y + z. I can jump through (manual) hoops to show that I have “y” licenses that match my “y” active users, but is there any point to doing this? If it is so compicated that I can'tdo it through the system, can PTC do it? If they can, then why won’t they share?

[AL_ANDERSON]

Have you tried using the out of the box Auditing functionality?

http(s)://your.server.com/Windchill-WHC/index.jspx?id=AuditAdminUsageReportManageWC&action=show

With one click, I got this information, below, for the last year from my
Windchill 10.1 system. I hid the thousands digit just because exactly how
many users we have isn't really everybody's business.


Ironically, given the current "PTC's documentation is bad" threads, the
on-line help for auditing is very good, and there are advanced Admin
guides that contain even more advanced information on auditing
capabilities that is also excellent. Sure, you have to go look, but once
you do, the documentation available around auditing if very good.

Al








[solutions] - RE: How does your company do a user audit in Windchill?

pete nelson

[pcnelson]

Thanks Al,

I think that's a good gross indicator but it really doesnt help with compliance. For instance, in your Feb numbers, if you have 450 licenses, but have created 700 users, and your graph shows only414 have acessed the system itgives you a false sense of compliance. As I understand it, any user who accesses the system must have an individual login (=license). So tracking the number of unique logins doesnt really help with the licensing issue. At least this is how the licensing hasbeen explained to me by PTC and several consultants. It's almost an honor system, with the possibility of a PTC audit helping keep people honest.

[AL_ANDERSON]

You are correct. However, with profiles and access control you can
control just about all functionality by group membership. If you want to
enforce local compliance, then design a set of "Read / Lite" groups and a
set of "Author-Admin / Heavy" groups. You then add up your unique "Read"
group memberships and your unique "Author-Admin" group memberships, and
make sure you are under your license limit.

As people leave the company or change jobs, you invent a business process
to remove them from their windchill groups. Additionally, you will want
to remove users who don't use their access. In that case, do an audit of
who logged in for a year or so, and have a business process to remove
those users who never logged in from their Read and/or Author-Admin groups
("use it or lose it").

This is a proactive limit on license enforced by Profile and Access
Control instead of a reactive (and not easily calculated) "please tell me
who actually used heavy stuff this year..."

Al Anderson








[solutions] - RE: How does your company do a user audit in Windchill?

pete nelson

[pcnelson]

Thanks Al, that explanation is very helpful and we already do what you outlined. What I naively had hoped for was the ability to run a report that would show, for example, the master View and Print group with all its sub-groups and the users contained in those groups. The response from PTC was that WC can’t produce a report dealing with Groups because that is handled outside by the LDAP. I can maintain a user listing like this outside the system, but then it’s not a real time picture of what WC contains. It just seemed that a system with the power of WC should be able to handle this. Do you have such a report? Thanks for your help here.

[AL_ANDERSON]

Here are the commands and the java source code to extract user and group
information.

windchill com.solar.report.acl.ACLUserRoleReportGen
windchill com.solar.report.acl.ACLReportGen

These classes generate group principal lists for all groups in Windchill.
The classes also take care of subgroups.
The output of each class is a ~ separated file that can be imported into a
text File. We typically look at them in Excel using text to columns.
There will be a lot of records, so don't use an old version of excel that
has a 60K row limit.
With slight modification to the RemoteMethodServer invocations' userId
and password logic, these can be reused.

Disclaimer: Use at your own risk! I cannot support these programs, or
answer any detailed technical questions about them, especially about
logging into your system using the remote method server API. For example,
you will find a custom method,
com.solar.auth.AuthenticationLogic.secureLoginTool.getWCUser(), that let's
us keep the password out of all of our source files like this one. You
will probably need to hardcode your password into your own program, or
write your own secureLoginTool (that I won't share here for obvious
reasons).

However, these files should help your own programmers get what you need to
audit your group memberships much more easily than you do now.

Source Code:


The report ACLUserRoleReportGen creates an output file with the following
columns.
Container Name|Group|Principal Name|User Id|User Email


The report ACLReportGen.java creates an output file with the following
columns.
Group|Description|Prinicipal Name|User Id|User Email


Al









[solutions] - RE: How does your company do a user audit in Windchill?

pete nelson