10 Replies Latest reply on Feb 19, 2019 5:30 AM by Deepak S

    AREA LDAP Authentication Not Working as Desired


      We are attempting to connect our Remedy accounts to an LDAP system (using the AREA plugin) for authentication purposes, and we have a question about Remedy’s Authentication Login Name (Field 117).


      Based on the documentation, our understanding was that we could add the Authentication Login Name (field id 117) to the User form and that field would act as an alias for the login process. Meaning – I could enter my email address into the alias field on the User form, leave my login name (firstname lastname) as the User Name on the form, and then log into Remedy using my email address and network password.


      In our testing, however, we discovered that the alias field and the user name field both had to have the same value, otherwise the authentication failed. Based on the logs, we believe that LDAP is still passing but Remedy itself is blocking the attempt. Is it true that the alias and the user name must be set to the same value, and if so, why? Doesn't that defeat the purpose of having an alias field?


      Seems simple enough, but are we missing something???


      Referencing Documentation we have reviewed to come to the conclusion that you should be able to have these two values be different:

      User Name Alias




      A User Name Alias is a secondary account name associated with a user and is used

      only for authentication purposes. The user’s primary account name (the login

      name entered into the User Name field of the Login dialog box of AR System

      clients) is used for all other purposes. If a User Name Alias is defined, the

      AR System server uses it to authenticate the user and password.

      The User Name Alias is applicable in the following situations:


      *When you want the user’s full name to be used as the AR System login instead

      of the user’s computer account name. The system uses the alias when

      authenticating the user.

        • 1. Re: AREA LDAP Authentication Not Working as Desired
          LJ LongWing


          I have never had the actual need to use this feature, but I agree with your assessment.  You would put 'Amanda' into the login id field, then 'amanda@comany.com' into the alias field, and when you log onto Remedy you would log on with amanda@company.com as your account name....I agree that you should not need them to be the same, as that would truly defeat the purpose.  I recommend turning on plugin logging to all, and figure out what value is being passed to LDAP when you have them different.  It SHOULD be the alias if I understand the feature properly.


          You failed to mention your version/patch level, but ensure you are on the latest patch for your particular version

          • 2. Re: AREA LDAP Authentication Not Working as Desired
            Mark Walters

            I think you've mis-understood what this field does.  The value set in the User Name Alias field is the one sent to the LDAP server for the user when they login - it is not an alternative login ID that you can enter as the Username of the login dialog.


            For example - you have a record in the User form for Bob, with login name Bob, and the User Name Alias is blank.  Assuming AREA LDAP is configured then a login attempt will result in the username Bob and password being sent to the LDAP server.  If you now enter bob.jones in the User Name Alias field, when Bob tries to login - still using the username Bob - the authentication details sent to the LDAP server would be bob.jones/password.  It does not allow you to use bob.jones as the Remedy login ID.  


            I hope that helps.



            • 3. Re: AREA LDAP Authentication Not Working as Desired

              Mark, Actually here is how I would think it would work based on the documentation:

              Login Name – bob jones

              Login Name Alias – bobjones


              I would think these two could be different based on the benefit mentioned in the documentation at the bottom of my post.


              My understanding is that LDAP authenticates on the Login Alias as long as the Password field is blank….which it does successfully. Then it seems as if it looks in the User form in the Login Name field to find a match in order to login as that user and not a guest.


              Scenario 1: Login Alias = bobjones; Login Name = bobjones SUCCESSFUL login with correct user/permissions

              Scenario 2: Login Alias = bobjones; Login Name = bob jones SUCCESSFUL login as a guest, no permissions


              So, if a benefit is to have these 2 be able to be different then why would it be looking to that field for validation that the user is found? Why wouldn’t it look to the Login Name Alias field (since that’s what it authenticated on) to find that match?


              I am really hoping that this is just a missed configuration on my part and this will happen the way we need it to. I do have a support case open with BMC for their assistance as well.


              Version AR Server 7.6.04 Patch 002

              • 4. Re: AREA LDAP Authentication Not Working as Desired
                Mark Walters

                When a user attempts a login the server will check for a record in the User form where the Login Name value equals that entered in the login dialog box.  If the Authentication Login Name field exists, and contains a value, then this is what is passed to the authentication source (LDAP, Windows) as the login name.  If the field does not exist, or is blank, then the login name is passed as is.


                So, AREA LDAP configured and working - User form records;


                Login Name     Authentication Login Name

                bob                         BLANK

                tom                         thomas


                When bob tries to login, using login name bob, the username value sent to the LDAP server will be bob.

                When tom tries to login, using login name tom, the username value sent to the LDAP server will be thomas.

                If a user tries to login using login name thomas, and there is no User form record with this Login Name value, the server will either refuse them access or log them in as a guest user if the option to allow this is set.  It will not search for a User form record with the Authentication Login Name value of thomas and log them in as this user.



                1 of 1 people found this helpful
                • 5. Re: AREA LDAP Authentication Not Working as Desired

                  I was afraid it worked like that….i was hoping that they could be different, otherwise I would have to wonder why have a second field? If you have ldap configured and the password blank then why not just be able to use the login name field to authenticate from instead of having to have two fields with the same value? I’m just not seeing the benefit of it or the purpose behind having two different fields where you have to have the same value in both. But again, maybe I am missing something.

                  • 6. Re: AREA LDAP Authentication Not Working as Desired
                    LJ LongWing


                    You missed something entirely in Mark's post.  He is saying this


                    Login     Alias         Passed to LDAP

                    bob                        bob

                    tom      thomas        thomas

                    frank    something  something


                    he is not saying that they need to be the same...he is saying that they provide what is in the login field, and if anything exists in the alias, the alias is used  for authentication to the LDAP server

                    • 7. Re: AREA LDAP Authentication Not Working as Desired

                      Oh, yes, I see what he is saying…so maybe I am still just confused as to why the option is given for them to be different b/c in the scenario given to me below:


                      Login      Alias      Passed to LDAP

                      bob                         bob

                      tom        thomas      thomas

                      frank      something   something


                      The 1st would work, but the 2nd and 3rd would always fail in finding a valid user and would potentially not log you in or log you in as guest (if you have that option checked). So, I see that LDAP is passing what I need it to in the Alias and is successfully binding, its just never finding a match in the User form b/c the login name is not the same as the login alias.


                      Does that make sense or am I still missing something?




                      • 8. Re: AREA LDAP Authentication Not Working as Desired
                        LJ LongWing

                        my understanding is that in the second example, the user would enter 'tom' as their user name, Remedy would pas 'thomas' to LDAP, LDAP would authenticate with the PW provided, and then, assuming that everything passed with LDAP, the user would be logged in with a user name of 'tom'

                        • 9. Re: AREA LDAP Authentication Not Working as Desired
                          Attachment Scanner

                          UPDATE: Based on File attachment policies, attached files were removed, see FAQ for more

                          • 10. Re: AREA LDAP Authentication Not Working as Desired
                            Deepak S

                            Even I thought like that. I can use either Login Name OR Alias Name as User Name of Login page for getting authenticating into Remedy. I actually have a requirement like this where in a user should be allowed to login with 2 different User Names but having single reference record in User forms and retain all the permissions. BMC has raised a defect on this scenario that they say Alias name should do this magic of login either with Login Name or The Alias name. Lets see. Meanwhile if anyone has idea for this please share.


                            Thanks in advace!!