This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
Hello all,
I'm (finally) getting to work toward a migration to Maximo 7.6 (currently on 6.2.6). I'm trying to figure out if we could possibly get Single Sign-On to work, at least in as many cases as possible.
Here's our situation and problems:
First, we have two directories, one for "staff" and one for college "students and faculty." And it is possible that someone could end up in both directories -- like someone who teaches a few classes but also works a regular job part-time.
Second, I'm concerned about how the integration will identify people. How we've been doing things -- in Maximo, when I create a Person record, the PersonID is FirstName + LastName + IDNumber (each student, staff, and faculty member has a unique ID number, and they are all created from the same list -- no two people would have the same ID number). For example, my PersonID would be something like TRAVIS HERRON 123456. We chose this to make it easy on supervisors when trying to fill in the Lead field on a work order, for example. They'd already know the "right answer" -- the ID -- that goes in the field; they wouldn't have to do a lookup. I really don't want to depart from this process. As an example of why this worked well. . .at one point, we had three men named David Brown concurrently working for us. One was full-time staff, the other two were students working part-time to help pay their tuition. Incorporating the ID number into the PersonID seemed like a good way to keep them distinct.
Then, for convenience sake, if that Person becomes a User, I would use the PersonID as the UserID, but that does not have to be so. Finally, the Maximo User Name would just be FirstName + LastName. In other words, the PersonID but without the ID number.
Current practice for IT on AD is Users are FirstInitial + LastName, unless that is already in use in that domain and then they'd go with FirstName + LastName (and I don't know what they'd do in the event they still had duplicates there -- I assume they'd hope one goes by a nickname, like make one "Dave' and the other "David"). Some folks, like me, have user names under the old format, which was always FirstName + LastName. They do seem to have that unique ID stored in a separate field in AD.
So the question is: I'm assuming that LDAP integration is going to propagate information to Maximo; that it is going to create Users in the MAXUSER table. That should mean it is going to create Person records too. If that is the case, is it possible to use LDAP integration and still have it convert the PersonID's to the format I want? Or is there some other way I can achieve what I want -- which essentially is, if they are logged in to the computer in our "staff" domain using a staff domain Windows user account, and they go to Maximo it automatically lets them in; otherwise they get the traditional login page.
Thanks for any help you can offer,
Travis Herron
We use two directories (forests) for our SSO implementation, so it will work that way. You have to create separate instances of the VMM jobs, one for each directory. The rub with that set up is that the AD user IDs have to be globally unique, not just unique within that directory. Otherwise SSO fails. We also had to create groups on both sides for our implementation, although I believe that is because our IT department does not have trust configured properly between the two sides.
As for your naming convention issue, that seems like it might be quite a challenge. OOB, the VMM job creates the user and person using the MSAD user ID for both. We simply gave way to the AD convention. Even after years of having this in place, it still comes up occasionally that we will have to change an existing personId from the back end if they become a user. I suppose theoretically you could write your own process to bring the users in to Maximo from AD instead of using VMM in order to use your convention instead of OOB.
I'm not sure about your idea of a hybrid approach. If I recall from configuration, there is a setting for security type in one of the web configuration files, an its either one or the other. Maybe it would be possible to have two separate instances running against the same DB, one SSO and one not, and to redirect from the SSO to the non-SSO on SSO failure.
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Wednesday, April 15, 2015 1:51 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Need help with LDAP for Max 7.6
Hello all,
I'm (finally) getting to work toward a migration to Maximo 7.6 (currently on 6.2.6). I'm trying to figure out if we could possibly get Single Sign-On to work, at least in as many cases as possible.
Here's our situation and problems:
First, we have two directories, one for "staff" and one for college "students and faculty." And it is possible that someone could end up in both directories -- like someone who teaches a few classes but also works a regular job part-time.
Second, I'm concerned about how the integration will identify people. How we've been doing things -- in Maximo, when I create a Person record, the PersonID is FirstName + LastName + IDNumber (each student, staff, and faculty member has a unique ID number, and they are all created from the same list -- no two people would have the same ID number). For example, my PersonID would be something like TRAVIS HERRON 123456. We chose this to make it easy on supervisors when trying to fill in the Lead field on a work order, for example. They'd already know the "right answer" -- the ID -- that goes in the field; they wouldn't have to do a lookup. I really don't want to depart from this process. As an example of why this worked well. . .at one point, we had three men named David Brown concurrently working for us. One was full-time staff, the other two were students working part-time to help pay their tuition. Incorporating the ID number into the PersonID seemed like a good way to keep them distinct.
Then, for convenience sake, if that Person becomes a User, I would use the PersonID as the UserID, but that does not have to be so. Finally, the Maximo User Name would just be FirstName + LastName. In other words, the PersonID but without the ID number.
Current practice for IT on AD is Users are FirstInitial + LastName, unless that is already in use in that domain and then they'd go with FirstName + LastName (and I don't know what they'd do in the event they still had duplicates there -- I assume they'd hope one goes by a nickname, like make one "Dave' and the other "David"). Some folks, like me, have user names under the old format, which was always FirstName + LastName. They do seem to have that unique ID stored in a separate field in AD.
So the question is: I'm assuming that LDAP integration is going to propagate information to Maximo; that it is going to create Users in the MAXUSER table. That should mean it is going to create Person records too. If that is the case, is it possible to use LDAP integration and still have it convert the PersonID's to the format I want? Or is there some other way I can achieve what I want -- which essentially is, if they are logged in to the computer in our "staff" domain using a staff domain Windows user account, and they go to Maximo it automatically lets them in; otherwise they get the traditional login page.
Thanks for any help you can offer,
Travis Herron
Alright, I've done a bunch more reading, study of XPath, XML, and XSLT, and I'm convinced there's a way to make it work, just got to modify LDAPSYNC.XML or VMMSYNC.XML.
However, after further study of our Active Directory implementation, I'm convinced I want as little to do with it as possible.
So here's my new desire: We have a database of employees, and a database of students. Neither of these, from what I understand, "talk" to AD. Yeah. So I want to, later, set up an import of the data from those databases. There's just more and better data to be had there.
But I still want to authenticate with AD -- and NOTHING more. So
mxe.UseAppServerSecurity=1
But also I think I need to:
mxe.LDAPGroupMgmt=0
mxe.LDAPUserMgmt=0
mxe.AllowLDAPUsers=0
So, what I'm hoping to do with those settings, is manually make the Users and put them in Security Groups, and make the LoginID the same as their network login ID (the sAMAccountName), with the goal being that we could still achieve Single Sign-On.
The questions are: Anyone know if that will work? And/or, what are the absolute bare minimum requirements for Single Sign-On?
Travis Herron
I "think" as long as MAXUSER.LOGINID matches the user ID in AD, authentication should work fine, regardless of the source of the data.
-Chris H
-----Original Message-----
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Friday, April 24, 2015 9:43 PM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Need help with LDAP for Max 7.6
Alright, I've done a bunch more reading, study of XPath, XML, and XSLT, and I'm convinced there's a way to make it work, just got to modify LDAPSYNC.XML or VMMSYNC.XML.
However, after further study of our Active Directory implementation, I'm convinced I want as little to do with it as possible.
So here's my new desire: We have a database of employees, and a database of students. Neither of these, from what I understand, "talk" to AD. Yeah. So I want to, later, set up an import of the data from those databases. There's just more and better data to be had there.
But I still want to authenticate with AD -- and NOTHING more. So
mxe.UseAppServerSecurity=1
But also I think I need to:
mxe.LDAPGroupMgmt=0
mxe.LDAPUserMgmt=0
mxe.AllowLDAPUsers=0
So, what I'm hoping to do with those settings, is manually make the Users and put them in Security Groups, and make the LoginID the same as their network login ID (the sAMAccountName), with the goal being that we could still achieve Single Sign-On.
The questions are: Anyone know if that will work? And/or, what are the absolute bare minimum requirements for Single Sign-On?
Travis Herron