Client-principal error

Posted by gdb390 on 25-May-2018 03:10

Openedge 10.2B0710 

In my login screen of the application when the user presses the OK button (after filling out the password en username) , I create a client-principal object.  

All goes well, the sealing is OK, but when I try to set the client-principal to all connected databases I get an error 

Same problem with statement security-policy:set-client (vhCP) or with statement set-db-client(vhCp)

the error is Client-principal:authentication-faild error because object is sealed (14549) 

anyone an idea ? 

All Replies

Posted by Simon L. Prinsloo on 25-May-2018 04:05

Sounds like one or more of your databases tries to authenticate the principal against its own domain registry, rather than trusting the one that you sent.

Check if the "Use application domain registry" option is switch on, or alternatively that the domain exists in the database with the same passkey.

Posted by gdb390 on 25-May-2018 06:30

Should the domain exists in every connected database ?

Posted by Peter Judge on 25-May-2018 07:52

A domain with the same domain name and the same domain access key must exist in each database where you are trying to assert the identity against. You do not need the user names, and you can use the _extsso authentication system (IIRC).

Posted by gdb390 on 25-May-2018 08:01

I loaded the domains in every connected database and the error is gone

however when I change an auditing enabled record , the userid is blank in the auditing table

I set the "use application user id" setting in the database options

Posted by gdb390 on 25-May-2018 08:19

apparently there is a difference between

* security-policy:set-client (vhCP).

* set-db-client (vhCP).

the auditing user is only filled in with the first statement

Posted by Tim Kuehn on 25-May-2018 10:11

There are two distinct aspects to CP - the setting for each DB and the setting for the session.  These values can be different, which is not immediately clear from the docs.

set-db-client sets the CP for a single DB

(I believe) security-policy:set-client sets it for the session *and* all connected DBs.

If one of the db's does not have the corresponding domain / access code then it can reject the CP which is what I believe you're seeing.

This thread is closed