ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Password Change Sync/Management with Active Directory (and other apps)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Password Change Sync/Management with Active Directory (and other apps)

    We are wanting to sync password changes across multiple applications; primarily between Active Directory and the iSeries. We have two ways we are currently exploring. We had some questions and would appreciate any feedback from anyone. We will only select one official path and make everyone change their passwords to confirm to the the process.

    1) Password Change Initiated by IBMi: Users will change their, through the green screen. There will be a hook in the password change program that will call a PHP Web Service, pass the username and password. This Web Service will then change Active Directory. I currently have the PHP Web Service running and can hit a web page that will change the Active Directory password. The questions I have on this route is: A) How can I call this web service and pass variables from an RPG program? I have the RPG program calling the web service, but can't figure out how to get the variables in the URL string. B) Is there a way for the RPG to recieve a success or error XML response from the web service for further processing on the RPG side?

    2) Password Change initiated by Web Service: Users would visit a web page and be prompted for username, current password and new password. On submit, a call is initiated to Active Director for the password change (currently working), and then would call the IBMi to initiate the password change. Is there a way for PHP to initiate a call to the IBMi, pass the username and password to initiate the change? I wasn't sure if there were any IBMi APIs, but through about writing another web service located on the Zend Server that will call an RPG program; passing the username and password to that program.

    Note: The current PHP Web Service I have referred to is currently running on a Linux Server. We tried placing this script on the Zend Server/IBMi, but could not get the LDAP to bind. Had no issues when we moved the script to a Linux/NginX server. I would eventually like to get this running from the IBMi, but taking small steps!

    I would prefer the 2nd method and have the PHP Web Service initiate the password change. This way, I can easily adapt other applications we have and bring those into the password change system. Most of our users have iSeries and AD accounts, but there are a few that have one or the other. We also have another application that I would like to write a hook to change the password on it, too.

    Any help or guidance is appreciated.

    JA

  • #2
    Re: Password Change Sync/Management with Active Directory (and other apps)

    What version of the OS are you running?

    Have you looked into EIM (Enterprise Identity Mapping) and rejected it for some reason? Here's the v7.1 link: http://pic.dhe.ibm.com/infocenter/is...2Frzalvmst.htm but I think is has been available as far back as V5R3.

    Robert
    Last edited by Robert Clay; April 14, 2014, 09:05 AM.
    "Contrariwise, if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic."--Tweedledee

    Comment


    • #3
      Re: Password Change Sync/Management with Active Directory (and other apps)

      I have not seen that. We are running 7.1. I'm going to dig into this a little more.

      When we were on version 5, there was something in place that synced the two. But we were also running some sort of virtual server/blade in the iSeries that held a Windows Domain Controller. When we upgraded to a new iSeries box last fall, we lost the sync. We ended up migrating the Windows 2003 server to a VMWare Virtual Machine.

      JA

      Comment


      • #4
        Re: Password Change Sync/Management with Active Directory (and other apps)

        After doing some quick reading, I don't think the EIM will work. EIM looks to be a great solution for Single Sign On; if your users are running the Client Access. A lot of our users are on thin clients that have a built-in 5250 emulator. I don't believe the EMI would work for these users. It looked promising at first until the requirement of having the Client Access acting as the session manager for Kerberos.

        Please correct me if I misunderstood.

        Comment


        • #5
          Re: Password Change Sync/Management with Active Directory (and other apps)

          I don't think that's true. I just downloaded the PDF and searched through it and the only reference I saw to IBM Access for Windows was for the administration of EIM (setup, maintenance, etc.). Since your 5250 emulators were using Kerberos tickets before (or, did I read that into what you were saying about the AD), it seems illogical that they couldn't going forward.

          I may be wrong, though. We don't actually use EIM here but maybe someone else will chime in who does.
          Last edited by Robert Clay; April 14, 2014, 12:29 PM.
          "Contrariwise, if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic."--Tweedledee

          Comment


          • #6
            Re: Password Change Sync/Management with Active Directory (and other apps)

            Robert. No, we did not use Kerberos Tickets with our 5250 emulators/thin clients. We did not have integration like that. In the past (prior to our upgrade), when we changed the password in the iSeries, it would replicate over to Active Directory. If we changed the password in Active Directory, it would NOT sync with the iSeries. In fact, the iSeries would update the Active Directory password to what the iSeries had. I'm not sure how this was working or what they did. I was told it was something to do with the "blades" that were in the iSeries and they had some sort of special integration with Active Directory.

            Comment


            • #7
              Re: Password Change Sync/Management with Active Directory (and other apps)

              Why not use SSO?
              Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

              Comment


              • #8
                Re: Password Change Sync/Management with Active Directory (and other apps)

                Why not use SSO? Not all of our clients use (or are not able to use) Client Access. We also have other systems that we would like to update the passwords on; but those will be in the future. Our primary focus is on the iSeries/Active Directory. We would like to eventually have a long-term strategy that may incorporate SSO, but that is the future and we are trying to work with what we have now.

                There looks to be a way to create a procedure in DB2 that would do the change password. http://publib.boulder.ibm.com/infoce...s/QSYCHGPW.htm. I think I may try to execute this procedure from my PHP program; thus avoiding having to work with RPG/CLI. Anyone tried this approach?

                Comment


                • #9
                  Re: Password Change Sync/Management with Active Directory (and other apps)

                  Originally posted by jason.aleski View Post
                  Not all of our clients use (or are not able to use) Client Access.
                  Who are your "clients"? That is, is that a reference to "customers" or "client software for users"? Client Access is not a requirement; it's just one of many software packages that can participate.

                  However, Kerberos is a requirement for single sign-on (SSO). Generally, the client software alternatives that don't support Kerberos are those that are free-ware and a few others. E.g., I haven't seen Mochasoft TN5250 supporting Kerberos even in the paid version, but many other TN5250 products do.

                  Also, even with SSO in use, exceptions can be made for individuals. While a large majority of users should participate (and therefore probably have their passwords removed from the iSeries), others may be allowed to work either way. Perhaps the fraction is small enough to be manageable...?
                  Tom

                  There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                  Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                  Comment


                  • #10
                    Re: Password Change Sync/Management with Active Directory (and other apps)

                    Definition: Cients - Devices or software used by internal employees. Such devices include desktop PC's running IBM Client Access and Computer Lab International AG Thin Clients running built-in 5250 emulator.

                    The Thin Client users also connect to a Remote Desktop session (which is also built into CLI device) for other applications (but the remote desktop does not support IBM Client Access).

                    Clients running IBM Client Access do not have to re-enter their credentials because it uses the credentials from the Windows session (The passwords must match, though).

                    The SSO/EIM will not help those users running on thin clients/non-kerberos clients. What we are trying to avoid is making the user change their password in the IBMi, then log into Windows and change their password in Active Directory, then log into Lotus Foundation and change their password there. There is at least one more spot a hand-full of users will have to change their password. Even if we walk them through the process, we have users what will not enter the same passwords in each system. I've seen users enter all caps in one system, all lower case in another, then add a space behind the password in the third system. It is these users are who I'm trying to target with my program.

                    Comment


                    • #11
                      Re: Password Change Sync/Management with Active Directory (and other apps)

                      We're using a package called ADSelfService Plus from ManageEngine.com. It worked great when it worked, but at the moment we're waiting on a bug fix for it to properly sync our IBM i passwords again. Wish I could give a better endorsement -- it seems really nice and integrates well with Windows and ActiveDirectory and will allow syncing passwords with all our systems ... once the bug is fixed.

                      Comment

                      Working...
                      X