Error when successfully connecting to Pega with Active directory
Hello everybody:-),
I have to connect workers from my enterprise to Pega (7.3.1) with Active Directory, so I've used WebLDAP3 servlet and mapped properties, with native AuthenticationLDAPWebVerifyCredentials activity, and a ModelUser of the same unit to access the correct application.
These workers don't have operators in Pega. When they enter their AD username and password in the login screen, they connect successfully and their operators are created with correct AD properties and Pega AccessGroups.
But when the login screen opens, before they enter their username and password, this error immediatly appears on the login screen: "The information you entered was not recognized."
When they enter the information, it works very well, so I don't understand why this error appears before they enter the information. Did I forget something? Do I have to customize AuthenticationLDAPWebVerifyCredentials?
I'm french so sorry if I don't write english very well... Thanks for your answers:-), and have a nice day with Pega!
Accepted Solution
Pegasystems Inc.
IN
Hi,
I was able to reproduce the scenario.
When we give AuthenticationLDAPVerifyCredentials activity directly in the authentication service, this will happen.
In step 2 of this activity, it is expecting parameters UserIdentifier and Password which needs to be passed from AuthenticationLDAP activity to AuthenticationLDAPVerifyCredentials activity.
Since you are directly calling AuthenticationLDAPVerifyCredentials activity in the authentication service, these parameters are null initially and hence you are seeing error message which will come when username/password are null or incorrect.
Solution:
Use AuthenticationLDAP activity in the authentication service(WebLDAP3 in your case).
This activity is already calling AuthenticationLDAPVerifyCredentials in step 2 by passing username and pasword.
You won't see the error message when you launch the WebLDAP3 servlet url.
Thank you,
Adithya
CNAV
FR
Hello Adithya:-),
And thank you for your quick answer! But when I use AuthenticationLDAP activity, the login screen doesn't open, and I directly have this error in the browser: "Operator ID Unauthenticated or not available"...
Pegasystems Inc.
IN
Hi,
This should come when the authentication activity is not recognized by the authentication service.
Please check the spelling of authentication activity field and try opening authentication activity from authentication service rule itself.
If you are able to open the activity from authentication service, you won't face this error.
Thank you,
Adithya
CNAV
FR
Hi Adithya:-),
Thanks again! Yes I can acess the activities from the service, here's a screenshot, and the exact error.
I've tried to use 4 activities in WebLDAP3:
- With AuthenticationLDAP or directly AuthenticationLDAPVerifyCredentials: the login screen doesn't open and an error appears in browser (shown in screenshot).
- With AuthenticationLDAPWeb: the login screen opens, no error appears, but when I enter username and password I can not connect.
- With AuthenticationLDAPWebVerifyCredentials: the login screen opens, an error appears, but when I enter username and password I can connect. Only this one seems to work although an error appears before I enter informations.
So I have a question: with AuthenticationLDAP, do I have to map the password, so that users don't have to enter it? I don't know where to find it in AD. Here's a screenshot of the properties I've mapped.
Pegasystems Inc.
IN
It seems you customized authenticationLDAP activity into your ruleset.
Make sure this rule is available to browser requestor.
You can trace the requestor to see where exactly this is failing.
- Identify the browser requestor ID when you see this error next time.
- Trace this by using remote tracer(designer studio) or from SMA
- reload the url to see the tracer contents
You do not have to map the password to make successful login.
CNAV
FR
Thank you Adithya:-),
The activity is not customize, but a requestor type was in my ruleset, so I remove it from my ruleset, and now the login screen opens with AuthenticationLDAP activity, that's a first good step!
But when I enter my username and password, the error appears again and I can not connect...
I've used the remote tracer, here's a screenshot, do you see something wrong?
I have a question about requestor types: I've seen two browser requestor types in my records, the one of Pega, and another created by someone in my enterprise (with no associated ruleset), so is it correct to have two browser requestor types, and how does Pega know the one to use?
It's already 19h50 in Paris, so I have to go back to home, I'll try again to solve the problem tomorrow!
Thanks again for your help:-).
Pegasystems Inc.
IN
From tracer, we can see ldap lookup is not successful(in step 2 of AuthenticationLDAPVerifyCredentials) and it is going to ERR step.
Check what exactly is going wrong there.
Which requestor type will be picked depends on the current systemname.
There are many ways to find systemname.
You can look for pySystemName in pxProcess page in clipboard>>systempages
The starting activity that gets executed is mentioned on activities tab of requestor.
CNAV
FR
Hello Adithya:-),
And thank you very very very much for your aswer, it helps me to resove the probleme:-).
I've added the AD directory context to the WebLdap3 search parameters (I thought it was not necessary since it is the same as the bind distinguished name), and now I can connect with AuthenticationLDAP without any error!
And I've seen the pxSystemName used in the clipborad, so now I better understand how it works...
I have another and last question to be sure I have well understood: what's the difference beetween AuthenticationLDAP and AuthenticationLDAPWeb? I think AuthenticationLDAPWeb need to receive the username from the browser url but I'm not sure.
Pegasystems Inc.
IN
You're welcome SandraA0.
There is only one difference between the two i.e., one extra step(step1) in AuthenticationLDAPWeb
As specified in the description of step1 in AuthenticationLDAPWeb, Additionally it can get the username from request header as well, I never used it though.