12 Replies Latest reply on Feb 15, 2016 3:59 PM by Scott Olswold

    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