Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
10.1 M040
I am trying to load EnterpriseLDAP users to an existing Org level group. The group DN is "cn=steelcase external,cn=public,o=steelcase
inc.,ou=people,cn=administrativeldap,cn=windchill_9.1,o=steelcase inc." and am using the command UserGroup. However I keep getting the below error. How can I get UserGroup to search higher up the tree in the local LDAP?
2015-09-22 08:20:18,284 INFO [RMI TCP
Connection(342)-10.80.96.61] wt.system.out wcadmin - Error detected in
createUserGroup <ABURGESS/Steelcase External>
2015-09-22 08:20:18,285 ERROR [RMI TCP
Connection(342)-10.80.96.61] wt.org.LoadPrincipal wcadmin -
at wt.org.LoadPrincipal.validatePrincipalFoundByDN(LoadPrincipal.java:1254)
at wt.org.LoadPrincipal.addMemberByDN(LoadPrincipal.java:1245)
Solved! Go to Solution.
Hi Patrick,
I worked on C12755759 with Mike Genovese today and I think we may have figured out the problem in this case. The full MS log you provided for the case yielded some clues.
Your MS log shows the following:
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Getting container path= ''
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - ERROR: Container path not set for this file, contact the author of the loadFile
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - FIX THE LOAD FILE SET!
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Using the Windchill PDM container. If it doesn't exist will use the exchange instead.
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Could not find Windchill PDM container, using exchange instead
2015-09-22 07:02:43,501 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out wcadmin - Using container with path= '/'
The lines in red indicate that the file is getting loaded into the Site level context. Since the Steelcase External group is an org-level group it can't find the group and is erroring out. You need to specify a CONT_PATH value pointing to the organization where the group exists in the LoadFromFile command.
We tested this out in-house with a group that is also defined in the AdministrativeLdap under the cn=Public... area and got similar results to what you were seeing when CONT_PATH was not specified. It worked if CONT_PATH pointed to the organization where the group existed:
We used the following XML:
<?xml version="1.0" ?><!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvUserGroup handler="wt.load.LoadUser.createUserGroup" >
<csvuser></csvuser>
<csvgroupName>AAAA</csvgroupName>
<csvgroupNameDirectoryService></csvgroupNameDirectoryService>
<csvuserName>ptcuser</csvuserName>
<csvuserNameDirectoryService></csvuserNameDirectoryService>
<csvDirectoryService></csvDirectoryService>
</csvUserGroup>
</NmLoader>
Also tried this with the same result:
<?xml version="1.0" ?><!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvUserGroup handler="wt.load.LoadUser.createUserGroup" >
<csvuser></csvuser>
<csvgroupName>AAAA</csvgroupName>
<csvgroupNameDirectoryService>com.ptcts.Ldap</csvgroupNameDirectoryService>
<csvuserName>wcadmin</csvuserName>
<csvuserNameDirectoryService></csvuserNameDirectoryService>
<csvDirectoryService></csvDirectoryService>
</csvUserGroup>
</NmLoader>
We then used the following command to successfully load the file:
windchill wt.load.LoadFromFile -d Add_Group_Principals.xml -u wcadmin -p wcadmin -CONT_PATH \"/wt.inf.container.OrgContainer=PTC\"
I think if you update your loadFromFile command to specify the CONT_PATH to point to your organization then the load will be successful.
Could you add the xml or the csv?
UserGroup | Steelcase External | ABURGESS |
sorry this is the one I tried.
UserGroup,,Steelcase External,com.steelcase.Ldap,ABURGESS,com.steelcase.EnterpriseLdap,
#UserGroup,user,groupName,groupNameDirectoryService,userName,userNameDirectoryService,DirectoryService
UserGroup,,Engineering,,ad_testuser,,
Try to leave the others blank.
May be it is better Idea to convert the csv file to xml.
Copy the csv file to <WT_HOME>\src\loadFiles and run windchill wt.load.util.CSV2XML <filename> you get xml file from same location.
yes I know how to do this. csv vs xml is NOT the problem.
It seems like it's not finding the Steelcase External group in the com.steelcase.Ldap directory service. Can you confirm that that is the directory service where this group is defined? Or maybe it's defined in the com.steelcase.AdministrativeLdap?
UserGroup,,Steelcase External,com.steelcase.AdministrativeLdap,ABURGESS,com.steelcase.EnterpriseLdap
Lori,
What is this loader expecting for the parameters groupNameDirectoryService and userNameDirectoryService? Should they be the names of LDAP adapters in the Info*Engine Administrator? If so then my AdministrativeLdap adapter is called com.steelcase.Ldap.
It should be expecting the directory service name for these fields. If you leave the field blank it searches the Administrative LDAP by default.
What is displayed for the distinguished name for the group in Windchill?
To verify that the administrative directory service has this group defined try pulling up the Access Control Rule Editor, specify the Admin Ldap directory service and search for the group on the Groups tab:
The DN for the group is "cn=steelcase external,cn=public,o=steelcase inc.,ou=people,cn=administrativeldap,cn=windchill_9.1,o=steelcase inc." As you can see my group for some reason is NOT defined within the people ou. For some reason I have cn=public,o=steelcase inc. above ou=people. This is a system upgrated from 9.1 so that may be the cause.
The Policy Administrator doesn't seem to have a problem finding the group.
Does it make any difference if you use net.steelcase.na.Ldap for the group directory services name rather than com.steelcase.Ldap when you try to add the user to the group?
Here is my LDAP admin window so you can see the JNDI adapters. I tried using the below in the xml file but I still get the error.
<csvUserGroup handler="wt.load.LoadUser.createUserGroup" >
<csvuser></csvuser>
<csvgroupName>Steelcase External</csvgroupName>
<csvgroupNameDirectoryService>net.steelcase.na.Ldap</csvgroupNameDirectoryService>
<csvuserName>ABURGESS</csvuserName>
<csvuserNameDirectoryService></csvuserNameDirectoryService>
<csvDirectoryService></csvDirectoryService>
</csvUserGroup>
2015-09-25 08:21:49,719 INFO [RMI TCP Connection(1707)-10.80.96.51] wt.system.out wcadmin - Error detected in createUserGroup <ABURGESS/Steelcase External>
2015-09-25 08:21:49,719 ERROR [RMI TCP Connection(1707)-10.80.96.51] wt.org.LoadPrincipal wcadmin -
wt.util.WTException: No principal was found for the dn: cn=Steelcase External,ou=people,cn=AdministrativeLdap,cn=Windchill_9.1,o=Steelcase Inc.
Hi Patrick,
I worked on C12755759 with Mike Genovese today and I think we may have figured out the problem in this case. The full MS log you provided for the case yielded some clues.
Your MS log shows the following:
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Getting container path= ''
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - ERROR: Container path not set for this file, contact the author of the loadFile
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - FIX THE LOAD FILE SET!
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Using the Windchill PDM container. If it doesn't exist will use the exchange instead.
2015-09-22 07:02:43,500 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out - Could not find Windchill PDM container, using exchange instead
2015-09-22 07:02:43,501 INFO [RMI TCP Connection(165)-10.80.96.61] wt.system.out wcadmin - Using container with path= '/'
The lines in red indicate that the file is getting loaded into the Site level context. Since the Steelcase External group is an org-level group it can't find the group and is erroring out. You need to specify a CONT_PATH value pointing to the organization where the group exists in the LoadFromFile command.
We tested this out in-house with a group that is also defined in the AdministrativeLdap under the cn=Public... area and got similar results to what you were seeing when CONT_PATH was not specified. It worked if CONT_PATH pointed to the organization where the group existed:
We used the following XML:
<?xml version="1.0" ?><!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvUserGroup handler="wt.load.LoadUser.createUserGroup" >
<csvuser></csvuser>
<csvgroupName>AAAA</csvgroupName>
<csvgroupNameDirectoryService></csvgroupNameDirectoryService>
<csvuserName>ptcuser</csvuserName>
<csvuserNameDirectoryService></csvuserNameDirectoryService>
<csvDirectoryService></csvDirectoryService>
</csvUserGroup>
</NmLoader>
Also tried this with the same result:
<?xml version="1.0" ?><!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvUserGroup handler="wt.load.LoadUser.createUserGroup" >
<csvuser></csvuser>
<csvgroupName>AAAA</csvgroupName>
<csvgroupNameDirectoryService>com.ptcts.Ldap</csvgroupNameDirectoryService>
<csvuserName>wcadmin</csvuserName>
<csvuserNameDirectoryService></csvuserNameDirectoryService>
<csvDirectoryService></csvDirectoryService>
</csvUserGroup>
</NmLoader>
We then used the following command to successfully load the file:
windchill wt.load.LoadFromFile -d Add_Group_Principals.xml -u wcadmin -p wcadmin -CONT_PATH \"/wt.inf.container.OrgContainer=PTC\"
I think if you update your loadFromFile command to specify the CONT_PATH to point to your organization then the load will be successful.
Thanks Lori! Specifying the -CONT_PATH command line parameter fixed it. I didn't specify this because other load files have worked properly without it.
Did you try to leave the ldap entries blank? Still the same problem?
Hi Patrick,
The Issue is the Steelcase External is not available at the node you are loading. There is a discrepancy in the DN. You are trying to load
dn: cn=Steelcase External, ou=people, cn=AdministrativeLdap, cn=Windchill_9.1,o=Steelcase Inc.
Where as the actual DN is
dn: cn=Steelcase External, CN=public, o=Steelcase Inc., ou=people,cn=AdministrativeLdap, cn=Windchill_9.1,o=Steelcase Inc.
Regards
Sudhakar
Yes I fully realize this however I have no control over 1) where in the DS the "Steelcase External" group was created and 2) how to specify a node above the search base within the Ldap.