16 Replies Latest reply on Dec 19, 2018 12:30 PM by Nikolay Karetnikov

    Pharos Blueprint in a multiforest environment

    Nikolay Karetnikov Navigator

      Hello!

      I'd like to bring up the subj. We have a perspective customer who is interesting in a card solution. This is one of the largest oil companies in Russia. They have currently installed Ringdale's solution, but actively seeking for alternatives. The thing is they have three AD forests and as they say no trust relationships whatsoever between those AD instances. The million dollar question is, will BP allow them to use "follow me" feature for each and every employee regardless of its AD membership (they envision sharing an MFP between different forest users).

      I currently see it as follows. An Analyst in the domain A with a csv imported lists of samaccountname from all other forests and a fleet connecting to the Analyst\Collectors using https protocol and non AD related pharos\pharos can actually do it, but the biggest concern is the other AD forests' users with the identical samaccountname, which is said they have a lot of.

      Could you please correct me if I'm wrong on my understanding how BP works in multiple forests environment and elaborate on the identical samaccountname issue?

       

       

      ps. If BP behavior in such a scenario varies from one version to other, we would be happy to use any of BP 5.x

        • Re: Pharos Blueprint in a multiforest environment
          Scott Olswold Guide

          Nikolay,

           

          If I understand correctly, you have the following:

           

           

          and you wish to allow access to Blueprint for Secure Release via card swipe.

           

          If this is the case, simply using sAMAccountName would not work, as "UserA" would end up in the data import twice, but will only appear in Blueprint once. And that record would have both cards registered, so each UserA would be able to release the other UserA's jobs.

           

          For this to work, each user would have to be in Blueprint as DomainA\UserA and DomainB\UserA, which is not something that Blueprint can support at this time.

           

          I am sorry.

           

          Regards,

          Scott

            • Re: Pharos Blueprint in a multiforest environment
              Nikolay Karetnikov Navigator

              Hello!

              Thank you for your reply! This is how I understand their environment.

              Any plans on implementing the feature this year or later on?

                • Re: Pharos Blueprint in a multiforest environment
                  Scott Olswold Guide

                  Nikolay,

                   

                  I've added your request to the Blueprint development queue. It will help us respond to customers that are in merger/acquisition mode, as well as larger multinationals that may be working to piece together disparate Active Directory implementations.

                   

                  Have a great day!

                   

                  Regards,

                  Scott

                    • Re: Pharos Blueprint in a multiforest environment
                      Nikolay Karetnikov Navigator

                      Thank you Scott for letting me know the problem is acknowledged and a resolution is on the way.

                      There were, however, some further developments somewhat related to the issue

                      Please consider the following scenario

                      Blueprint 5.2 is deployed in an Active Directory domain tree containing large number of subdomains.  More than 1000 employees from 3 domains: mt.company.ru, ce.company.ru, gd.company.ru use it on 5 different locations. HRLDAPUtility runs each night to sync Blueprint database with ActiveDirectory’s as shown in the screenshot below

                       

                      Sure enough there are the same sAMAccountName(s) in those 3 subdomains, but we are currently lucky enough not to have identical sAMAccountName within those 5 sites, so aforementioned troubles are not our concern for the moment. 

                       

                      The problem, nevertheless, arises with synchronization process. Suppose we have 3 identical  sAMAccountName in all 3 domains (e.x. personN@mt.company.ru, personN@ce.company.ru, personN@gd.company.ru). Among them the only personN@gd.company.ru has his employee record registered in the Blueprint database. Now, correct information gets into Blueprint storage only if we maintain MT, CE, GD sync order while running HRLDAPUtility. In other words this “order” approach leaves correct information  as long as corresponding to a BP’s person sAMAccountName(s) belong to either one domain or the domain that gets synced the last in the order.

                       

                       


                      As number of employees reached 1.5k and we have identical sAMAccountName(s) in more than 2 domains, the sync has to be stopped

                       

                      Could you please suggest a workaround?

                        • Re: Pharos Blueprint in a multiforest environment
                          Scott Olswold Guide

                          Nikolay,

                           

                          Because we do not current maintain the "domain" component of the identifier, the HRLDAP integration will cause problems in your above scenario. This is also something that is addressed within the development work around the previous ask.

                           

                          Regards,

                          Scott

                            • Re: Pharos Blueprint in a multiforest environment
                              Nikolay Karetnikov Navigator

                              Hello!

                              Thank you for the reply, it's clear, though very disappointing. Few records ( 2 out of 1.5k users it's less than 0.2%) stop the whole synchronization process. I believe that a patch for HRLDAPUtility that checks against an exception file would solve the problem and that is not something entirely impossible to do in just few days, isn't it?

                                • Re: Pharos Blueprint in a multiforest environment
                                  Scott Olswold Guide

                                  Nikolay,

                                   

                                  All of the importers (device, HR) work in the same way, and that is row-by-row. From their perspective, there is no history, no future--only now, and the record that is in the hopper. Since they "key" from the field specified as the sAMAccountName, it is just a simple lookup, so as long as there is a match, it will update the record. In the meantme, it is possible to exclude the duplicates from the other locations. In the .importconfig file controlling the HR import, find the <FieldOperations> section and add something that looks like this:

                                   

                                                  <Field ColumnName="IdentifierData">
                                                      <Blank Value="UserA" />
                                                  </Field>

                                   

                                  and then recompile on the Analyst with the InstallUtil.exe command line. Within the .importconfig, the <IdentifierData> line most likely is configured as RejectRecordIfBlank="true", so those records won't import.

                                   

                                  Regards,

                                  Scott

                                  825-042-354

                                    • Re: Pharos Blueprint in a multiforest environment
                                      Nikolay Karetnikov Navigator

                                      Seems as a viable workaround. I'll try it and post how it goes.

                                      Thank you!

                                      • Re: Pharos Blueprint in a multiforest environment
                                        Nikolay Karetnikov Navigator

                                        Hello!

                                        Scott, I tried your suggestion and it proved to be a workaround. The duplicated records can indeed be ignored while importing csv files. There are though several drawbacks in it. As its underlying principal is an exclusion we should address all domain's import files but the one where a duplicate is the real registered person. With 3 domains it's alright, if we expand to 10 it's chaos. And most importantly - is there any limitations on how long the <FieldOperation> can be? We expect dozens of records

                                          • Re: Pharos Blueprint in a multiforest environment
                                            Scott Olswold Guide

                                            Nikolay,

                                            I understand completely. As your base increases, it becomes much like herding cats when there's a mouse running around the room. As the product moves towards a "forest" approach in user management, this will be a non-issue.

                                             

                                            Regarding your query: There is no limit...but in full transparency, the more field operations you introduce, the longer an import will take.

                                             

                                            All the best,

                                            Scott

                                              • Re: Pharos Blueprint in a multiforest environment
                                                Nikolay Karetnikov Navigator

                                                Hello again!

                                                Thank you for your picturesque reply

                                                As for the "forest" approach, I've been putting some thought on the issue and though not come up with any particular solution, still would like to post few ideas

                                                For starters, we've recently discussed with Edouard Kassymov that Blueprint seems to use printjob owner name to determine who can later release the job. Googling that I found this article PaperCut KB | Active Directory username length limitation

                                                which states that sAMAccountNAme attribute of the currently logged in user is used for it.

                                                 

                                                Next, here is the link for a software that's aliasing owner to a list of predefined values.

                                                http://www.pcounter-europe.com/support/kb/75396/

                                                so, it is possible to locally change a job owner.

                                                 

                                                If we could integrate pcounter functionality into a Local Tracker (local or installed on a Collector) wouldn't that create a workaround?

                                                  • Re: Pharos Blueprint in a multiforest environment
                                                    Scott Olswold Guide

                                                    Nikolay,

                                                    Using the Blueprint PrintScout in "Authentication" mode allows the user to insert an alias as the job owner. However, it still uses Active Directory/LDAP/X.500 to confirm the user credentials being entered, so you'd be, in effect, forcing users outside of Domain X to use credentials for Domain X to authenticate. You can keep this credential "in effect" for a pre-determined amount of time, but this may not be a viable solution to your issue...it depends on the customer and the attitude in the user community to the workflow.

                                                     

                                                    Regards,

                                                    Scott

                                                      • Re: Pharos Blueprint in a multiforest environment
                                                        Nikolay Karetnikov Navigator

                                                        Hello!

                                                        Scott, let me, please update this.

                                                        Experimenting recently with multi-domain environment I have found that using "Authentication" mode has some interesting effect.

                                                        Consider this

                                                        PC1.v-lexmark.com and ivanov@v-lexmark.com

                                                        PC2.sub.v-lexmark.com and ivanov@sub.v-lexmark.com. PC2 has Scout installed with Authentication Mode ON.

                                                        The result is given below

                                                         

                                                        As you understand the second sAMAccountName which is sub\ivanov as an alternative AD account = sub.v-lexmark\ivanov_sub. When Authentication script is run, he enters sub\ivanov_sub and the corresponding password and the job is "redirected" to ivanov_sub account in Blueprint even though it is stored in the "ivanov" folder. It can later be released from this single folder by both v-lexmark\ivanov and sub.v-lexmark\ivanov_sub using their corresponding cards\PINs.

                                                        This brings us very close to a solution for the multi-domain problem. The only problem in this implementation is that sub\ivanov must have this alias account sub\ivanov_sub in AD which is only used to authenticate.

                                                        So, the question is

                                                        Can we skip Authentication and just redirect somehow jobs to ivanov_sub account of Blueprint?

                                                          • Re: Pharos Blueprint in a multiforest environment
                                                            Nikolay Karetnikov Navigator

                                                            FYI

                                                            I have composed a script to use digital cardID as PIN code in order to redirect jobs to ivanov_sub account.

                                                            With this approach Blueprint can manage several users with the same sAMAccountName belonging to many sub-domains.

                                                              • Re: Pharos Blueprint in a multiforest environment
                                                                Scott Olswold Guide

                                                                I think we are talking about two separate things, so I want to figure out which one is of interest.

                                                                 

                                                                Scenario 1. Two separate employees in different domains.

                                                                Employee: Andrew L. Johnson

                                                                Domain: DomainA

                                                                Login ID: ajohnson

                                                                Email: ajohnson@mycorp.com

                                                                Card ID: 123456789

                                                                 

                                                                Employee: Alex B. Johnson

                                                                Domain: DomainB

                                                                Login ID: ajohnson

                                                                Email: abjohnson@mycorp.com

                                                                Card ID: 987654321

                                                                 

                                                                In this scenario, an import of sAMAccountName would result in "1" record within Blueprint, ajohnson. The associated details would be for the person who appears last in the import file (we'll say it is Alex in DomainB). If an identifier translator is used to map card IDs, then this one account would have two cards: 123456789 and 987654321. Any jobs that both Andrew and Alex print will land in a JobStore folder called "ajohnson" and the "ajohnson" print history would indicate recent jobs on both of the Collectors in use. When Andrew swipes his badge, he'll see his jobs as well as Alex's. Similarly, when Alex swipes his badge, he'll see his jobs as well as Andrew's. All activity would post to Alex's user account.

                                                                 

                                                                This is a non-working scenario. This is the scenario that Pharos is seeking to fix, such that the two remain separate entities.

                                                                 

                                                                Scenario 2. One employee with a login in different domains.

                                                                Employee: Andrew L. Johnson

                                                                Domain: DomainA

                                                                Login ID: ajohnson

                                                                Email: ajohnson@mycorp.com

                                                                Card ID: 123456789

                                                                 

                                                                Domain: DomainB

                                                                Login ID: ajohnson-b

                                                                Email: None

                                                                Card ID: None

                                                                 

                                                                In this scenario, Pharos recommends that an "Employee" record (Type 0) be created (for this scenario, we'll call this Employee record "ajohnson"). The "ajohnson" and "ajohnson-b" network IDs would be children to the "ajohnson" Employee record and the Card ID would bind to the Employee record as well. Jobs printed as ajohnson would be held in a JobStore folder called "ajohnson" on the DomainA Collector, and in a folder called "ajohnson-b" on the Domain B Collector. When the badge is swiped at a device, Blueprint will seek all jobs for ajohnson and ajohnson-b since they are children of the parent ID the card is bound to. All activity would post to the ajohnson account.

                                                                 

                                                                This is a working scenario that Pharos Blueprint has been designed to handle since its inception. The hierarchical user account construction allows multiple network accounts to roll up under one account for reporting and authentication/release purposes.

                                                                 

                                                                Alternately, the ajohnson-b account jobs could be simply (and permanently) delegated to the ajohnson account for release. All activity would post to the ajohnson account. This type of function has been available on the Tracker/Print Scout side since Blueprint 5.1 and most recently in the Pharos Print Center web application.

                                                                 

                                                                Which scenario are you trying to resolve? Your recent example seems to address Scenario 2.

                                                                  • Re: Pharos Blueprint in a multiforest environment
                                                                    Nikolay Karetnikov Navigator

                                                                    Hello, Scott!

                                                                    I've heard you have been promoted Congrats!

                                                                    My two recent posts address 1st scenario.

                                                                    The problem with #1 is not that Blueprint can not have two identical accounts but that end-client's IT department has to rename

                                                                    Employee: Alex B. Johnson

                                                                    Domain: DomainB

                                                                    Login ID: ajohnson

                                                                    to ajohnson_2 or something.

                                                                    I believe that I found a workaround as that Alex can continue working with his login ID while his documents and the documents of his namesake are not mixed up.