Oracle Advanced Security Option and Kerberos

[Douglas E. Engert]

Thanks, Tim, this does explain a lot, and I like the gssapi plugin
approach. We need to try and get Oracle to do this.

Tim Alsop wrote:

> Douglas,
> 
> Some more info for you :
> 
> In Oracle 7,8 and 9 there are 2 ASO adapters, one called "KERBEROS5" and
> the other called "CYBERSAFE". You can determine which adapter is used
> when you configure sqlnet.

What about 10? In the Netmanager? On windows, I only see KERBEROS5, NTS
and RADIUS as choices. Does it have to have CyberSafe installed before
it will show it?

> 
> The CyberSafe ASO Kerberos adapter uses GSSAPI. This is because we don't
> expose our native K5 protocol API to partners, or to any customers, and
> also (perhaps more importantly) it allows the CyberSafe Kerberos product
> installed to be changed/updated without having to install a new Oracle
> database/client. In this case, the GSSAPI library takes care of
> interfaces with the cred cache, additional protocols, KDC differences
> etc. 

Yes, that would solve many of the the problems, like more DES only,
the KRB5CCNAME parsing, and ticket cache type.

> 
> The other ASO adapter called KERBEROS5 is implemented by Oracle, using
> an old version of MIT Kerberos code which is embedded inside the Oracle
> product, so you don't have to install any Kerberos libraries yourself.

Doing an nm on the library, and looking at routine names. it does not
look like any MIT release I have even seen. That was why I was speculating
that it was from your product.

> This has many disadvantages because you cannot update the MIT code to
> the latest version, and have to rely on Oracle updating their code,
> which they did when they moved to Oracle 10.
> 

Yes, the DES only, cache type = 2  and KRB5CCNAME parsing are good examples
of where this had an effect.


> I hope you will agree, that the more appropriate architecture moving
> forwards would be to use GSSAPI, and have some sort of configuration
> parameter in sqlnet, so that the GSS library name can be specified. This
> will mean customers can use any GSSAPI library with Oracle software,
> apply their own mods, updates etc. without (a) waiting for Oracle to
> make same changes, and (b) installing a new version of Oracle just so
> they can improve security. Of course, it will also mean that Oracle
> won't need to 'embed' any Kerberos libraries in their product, and this
> will make supporting new customer requirements much easier than it is
> today. This is the approach used by Sybase and IBM with database
> products - both of them support Kerberos using a configurable GSS-API
> library.

I full agree! You say Sybase and IBM do this... That might be an option
if Oracle does not make some improvements.


> I talked to Oracle about 3 years ago, suggesting that they made
> these changes, but the product manager at that time was not able to
> convince others in Oracle development team that this was the 'way to
> go'.

I think a lot of people have talked to Oracle, over the years, and get
the same response...

> Maybe you will have more luck if you try again ?

Thats what this threadis all about.

> 
> I agree that the mapping needs to be improved. Our experience is that
> customers have difficultly with the way it works today because they
> cannot use existing database users, instead they have to create new
> users using the realm name as part of the username, and it has to be
> uppercase. 

Yes this is a show stopper. There is no way that we could transition
from one to another.


> This means, that a Kerberos principal user1 at DOMAIN and a
> principal User1 at DOMAIN would have their own unique passwords, but Oracle
> would authenticate them both as USER1 at DOMAIN (the Oracle username) even
> though they are different principals with different passwords :-)

That is sort of the the way Windows AD treats Kerberos, as case insensitive,
and we are learning to live with it.

> 
> I hope this helps ?

Sure does, OK, if we forward your note ot Oracle?

> 
> Thanks, 
> Tim
> 
> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf Of Douglas E. Engert
> Sent: 24 February 2006 16:16
> To: kerberos at mit.edu
> Subject: Oracle Advanced Security Option and Kerberos
> 
> 
> Oracle has had Kerberos support for about 10 years via the Oracle
> Advanced
> Security Option (ASO) formally know as Oracle Advanced Networking
> Option.
> There are a lot of articles from 1998-2003 on using the ASO but very
> little after.
> 
> A few simple changes could vastly improve the usability of the ASO.
> 
> The code appears to not have been kept up to date, as it only does
> single DES,
> and uses a type 2 ticket cache. But some selective features have been
> made,
> including TCP support for the KDC, and on a Windows box, the client can
> use
> the Microsoft ticket cache (and maybe SSPI) to the server on Unix using
> GSSAPI.
> It can delegate credentials to the server so one database server can
> authenticate to another as the user. Yet it has a simple bug with
> parsing
> of the KRB5CCNAME variable.
> 
> It is not clear what Kerberos code base is used, as the libs don't match
> the MIT or Heimdal.  Articles refer to CyberSafe Trust Broker
> interoperability
> so it may be CyberSafe.
> 
> The ASO uses the full principal name with realm as the Oracle username
> without
> any mapping from principal to Oracle username. The name is also limited
> to 30
> characters. The lack of a mapping makes it very difficult to add
> Kerberos support
> to an existing database.
> 
> 
> 
> 
> I am looking for other Kerberos sites that use Oracle with or without
> the ASO
> who would like to see the ASO improved. I would also be interested to
> know if
> you have approached Oracle on improvements, and what was their response.
> 
> Personally I believe there has been a lot of customer interest in
> improvements
> especially from the security people, but this may not have been
> communicated
> to Oracle by the DBAs that deal with Oracle. Or if it has, Oracle has
> not been
> able to see the big picture, and thus not much has changed in the last
> few years.
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444