Oracle 11g Password algorithm revealed: Kinda interesting how easy it is to crack Oracle passwords. Maybe this begs the question of whether databases should store passwords anyway? I am of the belief that Oracle and IBM should within their products support direct authentication against Active Directory for this type of functionality.
I totally agree with what James states - IBM, Oracle and others should be supporting direct authentication against Active Directory. What does that *really* mean? Good question, I'm glad you asked. Well, for one thing, it doesn't mean just LDAP authentication, in my opinion. Let's go a step further and request the Holy Grail, please! We want Kerberos-based authentication.
If we have Kerberos-based authentication the world of SOA, protocol transitioning, web services and multi-tier architectures is opened up in addition to enabling the Holy Grail - true end-to-end single sign-on. There's no reason for you guys (IBM, Oracle, etc) to feel that you have to own this piece of the puzzle. Isn't there enough value-add in the rest of your platform?
Technorati Tags:
Active Directory, Kerberos, identity management, IBM, Oracle
9 comments:
Great blog by the way Jackson. I've only ever been a reader here, but felt compelled to comment this time.
Before I say anything, I should point out I used to work for IBM Tivoli just so I can clear up that potential conflict of interest right up front and this comment can be taken into context. I don't anymore however. So I'm perfectly capable of being impartial...I hope :)
I want to ask a question and then point out what the standard IBM answer is going to be for the whole "authenticate natively against Active Directory" thing.
When you say you agree that "IBM, Oracle and others should be supporting direct authentication against Active Directory", do you mean to say ALL their products?
First of all, that'll never happen. Too many products, too many different brands, too many different teams, too many different product managers and so on.
That said, the IBM answer is going to be, "use IBM Tivoli Access Manager (TAM) in conjunction with IBM Tivoli Federated Identity Manager (FIM)" to front end all your web applications.
TAM actually does support AD as a native authentication directory. That aside, it can also be configured to accept Kerberos tokens from an AD environment where the user is already logged into a domain (assuming all the AD and TAM trust relationships are set up) and sign them into the TAM environment. So if an organisation uses TAM to front end their web environment and users log into an AD domain, they can get Single Sign-On via Kerberos tokens.
Next, the IBM sales person is going to upsell the customer to FIM by saying the TAM user context (aka principal) can be leveraged by FIM to generate the relevant SAML, WS-* or Liberty tokens for federated SSO, which can of course be leveraged by any SOA inclinations an organisation might have.
So there you go. Kerberos right through to SOA. It's not quite so simple I know. But IBM kinda has a story.
So having unwittingly dusted off my IBM hat and put it on, I shall take it off now and put it back in the cupboard :)
I don't know, Jackson - isn't comparing LDAP to kerberos like apples to eggs? LDAP is an access protocol, kerberos is an authorization system. And, last I looked, Active Diretory didn't have a "standard" based system for either...
Ian - Thanks for reading and especially for commenting on this post. While I'd love to see IBM just generically support auth'n to AD I realize that will probably never happen but I'd sure like to see the key IAM products do that.
Oh, the IBM up-sell "phenomena" I have seen many times! ;)
Drop me a line at Jackson.Shaw(at)gmail.com - I have a few questions for you.
Thanks again,
Jackson
Dave - Kerberos is an authentication protocol. By tying the Kerberos "auth-data" field to an application you can implement authorization so in this fashion one could say that I am mixing apples and oranges. However, the corollary to this in the LDAP world is using LDAP for authentication and then using LDAP for querying group membership for the user's authorization context. Auth'z isn't built into LDAP but you can implement it in that fashion. Auth'z is built into Kerberos.
Regarding Microsoft and its adherance to standards I'm afraid I have to disagree with you on both LDAP and Kerberos. They have implemented the standards. Here's a white paper I wrote on that topic while I was at MSFT:
http://www.microsoft.com/windowsserver2003/techinfo/overview/ldapcomp.mspx
Microsoft's Kerberos "issues" have been hashed out and debated for years. The fact of the matter is that MSFT has implemented the standard and many folks were ticked off at how MSFT used the "auth-data" field for authorization (the PAC).
Unfortunately or fortunately (depending on your viewpoint) the auth-data field is part of the Kerberos 5 standard and MSFT's use of that field is within the standard.
I agree completely Jackson. Apart from what Ian says (and having dealt with IBM, it seems spot on), in my experience there simply aren't enough people at vendors that really understand Kerberos... maybe the Kerberos Consortium will change that, we'll see I guess.
Sorry about those giants that fail to keep up with the OSS world...
Indeed Postgres do support LDAP, Kerberos, Active Directory Authentication And the Holly Grail that it can be done over SSL!
So keep smiling with the free world! No more excuses to ignore that option specially when it's professionally supported.
Dao - Thank you for reading and your comment. I took a quick glance at the Postgres web site and was pleasantly surprised to see the extended support they have for Active Directory, LDAP and Kerberos. Thanks for pointing that out!!!
I'm not trying to make you look stupid. These are simply the facts.
Oracle has supported Kerberos Authentication longer than MS has been using it.
MS didn't open up the PAC information until after it had been reverse engineered so it made it a bit difficult for other vendors to adopt.
It would have been nicer if MS supported GSSAPI.
It would be nice if MS had support 3DES kerberos as every other kerberos vendor did instead of creating RC4HMAC.
It would be nice if MS backported their AES credential support from 2008. (Oracle currently supports this)
It would be good if MS actually support other kerberos systems in a manner that made them look like machines and services.
I was in discussions with the exchange group that actually developed AD and the kerberos authentication and some MS members were bitterly dissapointed with the actual kerberos support so it is little wonder that it created some angst in the wider standards based community.
The issue is authentication against AD - not Kerberos support per se. Oracle's latest product that supports authentictaion of Unix/Linux boxes via Kerberos does so only against the Oracle Internet Directory. AFAIK - and please do correct me if I am wrong - that software *requires* OID and does not support an environment without OID "in the loop".
I was on the team that dealt with the PAC issue - very familiar with it. There was only one person at MS that took the documentation of the PAC and the release of that documentation to the public in such a stupid direction. Problem was he was a group vice-president and reported in to billg himself. Fortunately, he's gone now.
I may also be wrong - correct me please - but in the past Kerberos support from Oracle was a $$$ option (OAS?). With Microsoft it was included with the OS. Is Kerberos support now included at no additional cost with Oracle?
Post a Comment