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:-),
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!
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.
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?
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?