7 Replies Latest reply on Jun 22, 2015 1:44 AM by Daniel Johns

    Active Directory Integration Question - User Passwords

    Michael Ives Newbie

      Hello,

       

      I'm sorry if this has been covered already, but I was not able to find an answer to this exact issue in the Uniprint documentation or by searching on the forums:

       

      I have recently set up a Pharos Uniprint 9.0 server and have configured the adldaplogon.exe plugin to be able to read and import users from our Active Directory servers.  I am having a problem with their passwords, however.

       

      When performing an import, there is no option to retain their existing AD password for use in Uniprint and a separate password must be set for the user.  Is there any way to 'synchronize' a user's Uniprint password with their Active Directory one?  Ideally, we do not want users to have to maintain a separate password for printing and we would like their Uniprint password to update when they change their password in AD.  I don't mind if this has to be done outside of Uniprint itself, such as with a script and a scheduled task, as long as there's some way to keep the Uniprint accounts' passwords the same as AD.

       

      Is this possible to do?  If so, how do I go about configuring this?

       

      Any information would be greatly appreciated.

        • Re: Active Directory Integration Question - User Passwords
          Steven English Guide

          Hello Michael,

           

          The adldap plugin can/will check passwords, but to the best of my knowledge there is not any synchronization that occurs from the perspective of the plugin.  That being said, if a script is applied to the logon event of the bank assigned to a release station (for example), the password that is entered and sent to AD can be cached in the Pharos db when/if the script logic tells it to do so (such as when the credentials check out as valid).  Scripts can also be configured to not update the password in the Pharos db, so it just depends on how you are set up.

           

          Overall though, the passwords are not automatically bulk exported from AD and then encrypted and entered into the Pharos database.  This means that a user can change their password in AD and the password - if stored in the Pharos db - will be outdated until they log in at a location that triggers the calling of the script which ultimately would result in their password being updated and it achieving the appearance of synchronization (the passwords will match, but only because the password the user provided can be encrypted and stored in Pharos, not because it retrieved a password from AD and synced up).

           

          Ultimately, it sounds like the missing piece here is either with a script that updates passwords, or with a misconfiguration or understanding of what the executable itself does.  The plug essentially gives a thumbs up or down with regard to whether the credentials checked out, anything beyond that - account creation, password "synchronization", etc... - requires scripting and logic.

           

          Regards,

          Steven

          1 of 1 people found this helpful
            • Re: Active Directory Integration Question - User Passwords
              Michael Ives Newbie

              Thank you for the information!  I misunderstood how the plugin was being used by Uniprint.  I got that the executable itself it would check supplied credentials against AD and return an ok/fail result, but I thought that it was still using the Pharos password regardless, as services such as the "My Print Center" website rely on the user's password in the Pharos DB instead of AD.  It turns out that with the bank logon event set to the plugin, the popup client will ignore the Pharos password and go based on the AD authentication result.

               

              Edit: I also found where the bank setting was for Print Center and got that sorted out.

                • Re: Active Directory Integration Question - User Passwords
                  Steven English Guide

                  Michael,

                   

                  The only area this would not be accomplished in is the Pharos Administrator.  It will always authenticate to the Pharos db and require Administrator level permissions.  For pretty much all of the other services, it consists of getting the login event set on the bank that the service is set to use.  The Pharos Remote uses a special bank aptly named Pharos Remote Bank, and the Print Center can be configured to use the bank of your choice under the System > System Settings > Print Center there in Pharos Administrator.  One thing to be aware of with plugins and scripts on the Print Center is that if you allow guest users to register themselves, you will need a script in place to handle identification and authentication of those guest accounts so that authentication is redirected back to the Pharos db instead of being sent off to AD (we know authentication attempts against AD would likely fail unless the user happened to register an email address that will validate against your AD setup).

                   

                  Regards,

                  Steven

                    • Re: Active Directory Integration Question - User Passwords
                      Daniel Johns Tracker

                      One minor correction here: while it is true that Pharos Administrator will always authenticate to the Pharos DB, whether it will require Administrator level permissions is configurable: under System > System Settings > Permissions it is possible to give other classes of users access to some or all parts of it.  If you choose to do this, then the need to use passwords in the Uniprint DB might be a bit more of a problem for anyone who uses Active Directory passwords for other parts of the system.

                • Re: Active Directory Integration Question - User Passwords
                  Paul LaFollette Guide

                  This is an interesting item (to me).  We are looking at migrating to Uniprint 9 (currently on 8.4) and with our system we do not store the user's passwords in Uniprint except for the members of the Admin role.  Everyone else is simply a User. 

                   

                  We are having our Uniprint release station authenticate username and password against the AD and if the AD gives the "thumbs up" our Uniprint uses the AD authentication.  When importing users, we use the batch load method or a SQL script to add/update users in our Uniprint database... and we don't import the password, but the password field HAS to be specified in the import process, we just leave it blank/empty.

                   

                  I don't know if that is of any help.

                   

                  - Paul L.

                  1 of 1 people found this helpful
                    • Re: Active Directory Integration Question - User Passwords
                      Michael Ives Newbie

                      Thanks for the information!  Between both your post and Steven's, I figured out how the popup client was actually leveraging the plugin.  It turns out that for printing, the solution is much simpler than I thought because the Pharos passwords are ignored in favour of the AD authentication token.  I think I'm going to end up managing users in a very similar fashion to how you do it.

                       

                      I wish I could mark both answers correct, as you both were very helpful!

                        • Re: Active Directory Integration Question - User Passwords
                          Steven English Guide

                          Michael,

                           

                          If functioning within a SecureRelease environment (where users have to go somewhere to release their job as opposed to direct print which bills the job and prints automatically upon submission) and the release stations are configured to only show the jobs that belong to you instead of all jobs, there is usually little need to require authentication at the popup level since we know the user will be required to authenticate at the release station.  Setting the bank at the print server level would force authentication of all jobs.  This is a more complicated scenario and if configured as described above would not serve much purpose other than to prevent users without valid AD credentials from even submitting jobs.  Usually if they are on a machine, they have credentials of some kind, so I do not usually see much use for it except on direct queues/print groups.

                           

                          Regards,

                          Steven