I caught a post over at James McGovern's blog on Oracle Authentication Services for Operating Systems and tonight noticed a follow-up to it over at Oracle's own Mark Wilcox where he posted Understanding the Benefits of Oracle Operating System Security (OA4OS). Here's the whole post: (color highlights are mine)
Today is a day it catch up on some blogging.
James McGovern posted a few questions on our new operating system security product - aka Oracle Authentication Services for Operating Systems or OA4OS.
First quote - " On one level, this feels like a good story, but on another it feels like a long-term trap." It's just a good story :). There is no trap. Unlike competing solutions - we don't use any proprietary hooks or changes to the Unix /Linux systems. We are using all standard - based interfaces like PAM, NSS and SUDO.
Thus it would be possible to move to another directory solution.
Second quote - "First, if you are running Solaris, this you can setup NIS domains to aid in this problem." NIS has been out of favor for a while. It has now been officially deprecated. And for the kicker - it is not SOX compliant.
Thus many customer's we've talked to about OAS4OS are specifically looking for how to replace NIS. This is one of the features we offer.
Third quote - "Consider that if you are a shop running Active Directory, Microsoft provides Active Directory Services for Unix where by you can have Unix servers and daemons participate as if they are native to the Windows domain. This simplifies administration significantly, cheap to rollout and even cheaper over the lifetime. There are of course some features missing, which Microsoft will be addressing in upcoming releases."
Yes - Microsoft does offer this. However, it has many limitations that in many organizations will not be solvable. For starters - you must extend AD schema - in many organizations this is not allowed by corporate policy. Second, by storing this data this can add severe impact to your AD replication which affect desktop login (which is why this is not allowed by many corporate policies). Third - it does not auto-generate UID & GUID numbers (we do :)). Fourth - they do not have any system to allow you to address use case of where you have same username but different uid/gid numbers on different hosts (hello OVD)). These are all features that AD lacks and some (such as schema change) will never be avoided.
Final quote- "You can also consider third party software such as Vintela and Centrify which also provide deeper Unix/Linux integration to Active Directory. Anyway, I humbly predict that the open source community will realize that this type of integration should be in the box and not something add-on and therefore will address within the next six months."
To my knowledge Vintela and Centrify require proprietary components and/or extensions to AD. Also they don't provide any mechanism to manage SUDO policies in your directory. And I would also point out that this if our first release (if he can mention MSFT updating AD as being OK, I can use it hear for us too :)) so we are going to be adding in additional functionality in the future.
I take issue with the highlighted statements above...
1. Unlike competing solutions - we don't use any proprietary hooks or changes to the Unix /Linux systems. We are using all standard - based interfaces like PAM, NSS and SUDO.
I'm not sure who you mean when you say "competing" but let me state that our product (Vintela Authentication Services) uses no proprietary hooks and requires no changes to the Unix/Linux systems other than the same ones you use: PAM, NSS and SUDO. Mark, this is plain old FUD.
2. ...by storing this data this can add severe impact to your AD replication which affect desktop login (which is why this is not allowed by many corporate policies).
Also, by walking across the street I could get hit by a bus. Are you kidding me? I have never seen this happen in all my years working with Active Directory and Vintela Authentication Services. Severe impact to your AD replication? Man oh man. This was the FUD comment that really launched me. Schema extensions "not allowed by many corporate policies"?Any Microsoft customer that has installed Exchange or Live Communications Server has extended their schema. FUD, FUD, FUD.
3. To my knowledge Vintela and Centrify require proprietary components and/or extensions to AD.
I won't speak for others and I'll take into account your statement "to my knowledge" and, once again, state that Quest does not require proprietary components and/or extensions to AD.
Mark may not be familiar with RFC 2307. RFC 2307 is an IETF standard for representing NIS data in a directory service. Let me point out that Microsoft incorporated RFC 2307 schema extensions in the base Active Directory schema with Windows Server 2003 R2. Most of the customers I talk to that are running pre-Windows Server 2003 R2 have extended their schema to include the RFC 2307 extensions. Oh, and of the thousands of customers I have talked to I have never ran into one who has a corporate policy about not extending the schema. Again, more FUD.
4. Also they don't provide any mechanism to manage SUDO policies in your directory.
A quick search of the Quest website would have shown that not only does Quest provide a SUDO tool but it can be managed via Active Directory.
I'm going to save my comments on the new "Oracle Authentication Services for Operating Systems" product for another post. There's only so much fun and ROFLMAO that I can take in one evening...
Mark responds to my post here: http://blogs.oracle.com/mwilcox/2008/05/07#a240
He says he runs into customers all the time that can't extend the schema. My bet is he is running into EMPLOYEES who say they can't extend the schema. Extending the AD schema is not for the faint of heart and many companies have a policy about it but when push comes to shove they all extend. Otherwise, they would still be on Exchange 5.5.
Quest Software, Oracle, Active Directory, Microsoft, identity management