Skip to Main Content
Forums

Security Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Unable to configure directory authentication for Users as SYSDBA

Sudipto DesmukhJul 5 2016 — edited Jul 9 2016

We had a task where we were required to assign SYSDBA privileges to a certain user using Directory Authentication using EUS

Here’s the document & blog we followed -

How To Configure Directory Authentication for Database Administrative Users (SYSDBA and SYSOPER) (Doc ID 457083.1)

http://blog.yannickjaquier.com/oracle/enterprise-user-security-eus-password-authentication.html

But we get the following error –

[oracle@xovm1116 ~]$ sqlplus sdesmukh/Welcome1@eusOnWindows as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Jul 5 15:25:40 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

ERROR:

ORA-01017: invalid username/password; logon denied

However, since EUS is configured, the user is able to login fine as a non-SYSDBA user as shown below

[oracle@xovm1116 ~]$ sqlplus sdesmukh/Welcome1@eusOnWindows

SQL*Plus: Release 11.2.0.4.0 Production on Tue Jul 5 15:23:25 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Any ideas on what I could try or might be missing ?

Comments

Peeteba
Let's bring this one up again.

Anyone having an idea?
APEX development team maybe? Patrick Wolf? ...

I use this function very often so if I shouldn't do this anymore, it would be nice to know this.

Regards,
Bart
Answer
Hi Bart,

we have a newer API, it's called apex_authorization.is_authorized. Unfortunately, the documentation for this package didn't make it into 4.2.

Even in later releases, there are no plans to actually remove existing documented APIs. We just want to provide better encapsulated APIs and encourage people to use these, because apex_util is a bit unwieldy.

Regards,
Christian
Marked as Answer by Peeteba · Sep 27 2020
partlycloudy
Christian - Huh, didn't realize a new API had snuck into the distribution. apex_authorization looks very useful. Question about apex_authorization.reset_cache - Does including the APP keyword in the clear cache position of the f?p= URL do this as well? Or is using this new API the only way?
Hi Vikas,

the APP keyword only resets session state, not the cached authorizations. Can you give a use case where this should also reset authorizations?

Regards,
Christian
partlycloudy
Well, the APEX Builder has several declarative methods where we fill in various components of the f?p= URL and the engine constructs the f?p= URL. The use cases that come to mind are in apps that involve some sort of "emulate user" function which would basically do a "logout/login as some other user" but without actually logging out. In these cases, it would be handy if the APP keyword were to clear cached authorizations as well. Of course, there is almost always a page submit involved so it is just as easy to stick a call to apex_authorization.reset_cache in a after-submit component but I thought I would ask.

So, if I understand you correctly, using this new (in 4.x?) API is the only way to reset cached authorizations?
For "emulate user", I would use apex_authentication.post_login. This overwrites the user in the session and automatically resets authorizations. I guess it does not hurt to also reset on an APP clear cache request, but I would have to test this.

In releases before 4.2, the reset cached authorizations feature was already present via apex_util.reset_authorizations.

Regards,
Christian
Peeteba
Thanks Christian for the reply.
This explains the debug line. Maybe it would be less confusing to point out to the new API instead of just mentioning the used function is deprecated.

I took a quick look into the package specification and I'll start using the new API instead of APEX_UTIL.

Regards,
Bart
Anton Scheffer
Are there any more undocumented API's which people are encouraged to use, or is this the only one?
Hi,

the deprecation messages were a bit premature, as I tried to explain above. They should not have been added without proper documentation of the newer APIs and you can just ignore them for now. Maybe we will include a reference to the newer APIs in the messages in 5.0, that sounds convenient.

Regards,
Christian
Anton Scheffer
My concern wasn't about premature deprication, but about your current advise to use undocumented API's
I never gave that advice, but explained the reason for this message and that it was premature, since the documentation is still missing. These kinds of messages should encourage people to use newer APIs, but the debug messages should not have been included without docs.

Since doc for apex_authorization was only excluded by mistake and will be added in a later release, people can already use it in 4.2.x, if they want.
1 - 11
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 6 2016
Added on Jul 5 2016
#authentication, #directory, #identity-management, #oracle-unified-directory-oud-oracle-directory-server-enterprise-edition-sun-dsee
7 comments
1,480 views