WebKerberos service authentication
Hello everybody:-),
I try to connect to Pega application and read ldap properties with WebKerberos service and pyAuthenticationKerberosCredentials native activity.
I succeed to connect to Pega application (I'm recognized by the system) but fail to read ldap properties. I get a javax.naming.NamingException GSSAPI on line 136 in activity code: ctx = new javax.naming.directory.InitialDirContext(props); I think this error comes from line 76: props.put(javax.naming.Context.SECURITY_AUTHENTICATION, "GSSAPI");
This error doesn't stop the activity, it's only written in log file, and I access to the application, because the operator already exists and is recognized. But if the activity can't read ldap properties, if a user doesn't already exist, he won't be created and won't access to the application.
Do you know why this error occurs and how to resolve the problem?
Thanks in advance for your help:-),
Sandra.
CNAV
FR
Hi everybody:-),
I've traced the activity pyAuthenticationKerberosCredentials, and have this error in step 2: failed to get gssCredentials. I've saved the activity in my ruleset to add logs in java code, and I found gsscredential is null. Moreover the property pxUserPrincipalObject is not set, instead the property pxWebUserPrincipal is set.
I've modified the java code to use pxWebUserPrincipal instead of pxUserPrincipalObject, this allowed to get the kerberos ticket to connect the operator to Pega (if he doesn't exist he's well created), but I need to put my password in java code to get LDAP properties. It seems to me pxWebUserPrincipal is missing something.
I can use a generic user to get LDAP properties, but I think normally Kerberos or Spnego shoud retrieve all what's needed so that the connected user can get his own properties. So I wonder why gsscredential is null and why pxUserPrincipalObject is not set, perhaps it's a configuration problem, I don't know...
Did you alrerady use WebKerberos service? Do you have an idea where does the problem come from? I hope somebody can help me... Have a nice day anyway!
Sandra.
Pegasystems Inc.
IN
Hi Sandra,
Kerberos setup is complex. We need to configure many settings.
SPNEGO does Kerberos handshake and passes GSSCredentials to Pega application, then Pega application validates those GSS credentials with LDAP server.
We need to enable Kerberos Single sign-on to get valid GSSCredrentials from logged in uSer. You can refer https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w Dzone article to understand Kerberos Single Signon in general. You can refer attached Pega Kerberos documentation to understand Pega configuration to support Kerberos.
Note: Kerberos Single sign-on requires AD configuration as well so I suggest you enable Kerberos Sign on in your test Active Domain control. Even if you make mistakes, there won't any huge impact. Once you succeed, then you can implement it in production.
Let us know if you need any further help
Pegasystems Inc.
IN
you can refer this PDN article https://community.pega.com/knowledgebase/articles/using-kerberos-credentials-pega-application-authenticate-and-access-external
CNAV
FR
Hello Sivar:-),
Thank you very much for your message and sorry for my late answer!
Yes it's true this configuration seems complex to me because it needs many files settings that I don't kwow... My coworker (system administrator) verified every files and they all are correct according to him.
I've read some documentations and still have two questions:
- Does the user that tries to connect have to belong to a group in Active Directory that is mapped to the PegaAuthUser role?
- Our Pega is on a Jboss server, and the spnego-r7.jar is here: /opt/jboss/instances/8_Pega/tmp/vfs/deployment/deployment481d4b9f61b6549d/prweb.war-c0d0d14470939f37/WEB-INF/lib/spnego-r7.jar.
It looks like a temporary directory, do you think it's the correct place to put it?
I think the problem comes from spnego-r7.jar because the gsscredential is null and the pxUserPrincipalObject property is not set.
Instead the pxWebUserPrincipal property is set, so it means we get a kerberos ticket. But it contains only the user identifier and AD domain, not all credentials, as if it was not complete, do you have an idea why?
Thanks again for you help... And have a nice day!
Sandra.
CNAV
FR
Hi Sivar and every body:-),
The NamingException on GSSAPI make me think that perhaps another library is used instead of spnego-r7 although this jar is on our Jboss server.
May the problem come from my Firefox config?
Here are the values for some Firefox properties:
network.negotiate-auth.using-native-gsslib : default to true
network.negotiate-auth.gsslib : default to empty
network.auth.use-sspi : blocked to true
I wonder if I have to change these values so:
network.negotiate-auth.using-native-gsslib : change to false?
network.negotiate-auth.gsslib : .../WEB-INF/lib/spnego-r7.jar
network.auth.use-sspi : change to false?
I don't have the right to change all of these values, so I will ask to my admin to do it if you think I have to, do you think it can resolve the problem?
Thanks again for your advice or other ideas to help us:-),
Sandra.
Pegasystems Inc.
IN
Can you try to use IE (Internet Explorer) or Edge browsers?. These two browsers come with Windows operating system so servers while listing not required.
Please refer to section "6. Browser settings to support SPNEGO SSO on Windows machine" in the above attached Kerberos documentation (KerberosEPIC19232_Documentation.docx).
CNAV
FR
Hi Sivar:-),
And thanks for your new answer:-), yes I've read this documentation.
I only have IE 9 (I know Pega needs IE 11) and I don't have Edge. I can't upgrade IE or download Edge because I don't have rights enough on my computer.
I have Chrome and Firefox, the standard in my compagny is Firefox, and the two parameters trusted-uris and delegation-uris are already set.
I'll ask my compagny to get the rights to change use-sspi (I'm not sure it will resolve the problem) or to install IE 11 (I don't think it will be accepted).
I'll tell you if I resolve the problem... Have a nice day!
Sandra.
CNAV
FR
Hello Mukkp:-),
I didn' t really succed to resolve the problem, I only get around it using a technical account with known password. Thereby when a user connects to Pega, the technical account retrieves his AD attributes, to create his operator if it doesn't exist, or update his Pega properties if it does.
To do so I've customized the authentication activity (step 2):
First I get the pxWebUserPrincipal (username) instead of the pxUserPrincipalObject. I don't know why and how, but I noticed in the clipboard that pxWebUserPrincipal is set whereas pxUserPrincipalObject isn't. Is your pxUserPrincipalObject automatically and correctly set?
Then I replaced two lines with three others:
//props.put(javax.naming.Context.SECURITY_AUTHENTICATION, "GSSAPI");
//props.put(javax.security.sasl.Sasl.CREDENTIALS, gsscredential);
props.put (javax.naming.Context.SECURITY_PRINCIPAL, pega_rules_utilities.getDataSystemSetting("CnavAuthSA","ADUserTechPrin"));
props.put (javax.naming.Context.SECURITY_CREDENTIALS, pega_rules_default.Base64Decode(pega_rules_utilities.getDataSystemSetting("CnavAuthSA","ADUserTechCred")));
props.put (javax.naming.Context.SECURITY_AUTHENTICATION, "simple");
I hope this will help you... Tell me if you succed to resolve the problem without customize the activity!
And have a nice day anyway:-),
Sandra.