Slashdot Mirror
Windows 2000 Directory Support While Keeping Unix?
"Although our group has historically been able to control it's own authentication and name services, our agency, together with some other affiliated entities, has begun to develop plans for the deployment of W2K and Active Directory, agency-wide, and we are beginning to hear noises about the possiblity of it being implemented in a configuration that would move that control outside of our group for the first time. Given that we are the only dyed-in-the-wool Unix shop anywhere in sight, we're not counting on Unix-specific concerns carrying much weight in this discussion. FWIW, "Unix" in this case is mostly Solaris/SPARC, with a growing Linux and BSD flavor, both also on SPARC as well as x86.
Now, to get to the point, I have the following serious questions to which informed answers would be tremendously useful right about now:
- It is my impression, which may be incorrect, that (a) a W2K workstation using Active Directory services cannot directly access old, NT4-style SMB shares, and (b) neither Samba (at least any stable releases thereof) nor any commercial SMB-on-Unix implementations (not that I'd be at all happy to ditch Samba) is able to export Unix filesystems via the new, W2K-style protocol, or at least not in any way that would provide "seamless integration" with W2K clients that also needed to access AD/W2K-based resources. From these impressions I would conclude that AD-infected W2K workstations cannot be made to access Unix-native filesystems via SMB. Is this correct? If there are inaccuracies in this, or if it's "not really that simple", I'd love to know the details.
- It is unclear as yet whether we would somehow be forced to use AD/W2K-based name and authentication services for our Unix machines. Potentially, for authentication we could use the vanilla Kerberos interface in AD. However, for name and directory services to work fully, we are likely to need to be able to store RFC 2307-compiant data in the AD LDAP. So, leaving aside the question of whether we would even be allowed to store the RFC 2307 data in the agency's AD, are these things possible or practical?
- One concern we have about AD is the liklihood that we may have to use a subtree of the central AD for our group. In this event, we expect that some sorts of access and control are likely to propigate down from the top of the tree, and that we may ultimately not be able to have the final say over who has what permissions with respect to the resources supported by our group. Not to be territorial, but this raises some sigificant security concerns in that some of the data we process is quite sensitive (e.g. respondant-level survey data -- can you say "privacy concern"?) and the auditors will want to see assurances that access and distribution are properly controlled within our group. Is this a legitimate concern about a centrally-controlled AD? Are there some AD configurations that are less troublesome than others in this regard?
- Does anyone know of any other potential killer incompatibilities between AD/W2K and Unix that should be put on the table as we discuss our "requirements" (ha) with the central IT people who are trying to do this?
- Has anyone gone (is anyone going) through this who would be willing to share experiences?
For everyone who will no doubt respond to this by identifying all the better solutions that may exist, I'd love to do something like that -- we had been investigating doing something with Kerberos and OpenLDAP before this came up -- but the point is that the direction here is likely to be totally beyond our control, and we may wind up stuck with the task of finding some way to salvage whatever we can of fifteen years of investment in a Unix-based solution. I'm just trying to understand the pitfalls a bit better before all this is set in stone.
Here are three previous /. items that seem most relevent, so you know that you don't have to point me to these."
Atleast to my understanding, the Microsoft's implementation of Kerberos is uncompatible in a such way that the Directory service is only available while running W2K Kerberos server. W2K is able to authenticate from UNIX Kerberos server, but I've heard a claim that UNIX clients will be unable to authenticate from W2K Kerberos. None of this I have tried out myself, not willing to touch W2K with even a long, very, very long stick.
1. There's no reason why a workstation participating in an Active Directory domain shouldn't be able to access older style NT or Samba shares. There are a few departments where I work that have (stupidly) deployed Active Directory, but it hasn't affected their access to our NT 4 file server. Well, except that they have no idea what they're doing, so that gets them sometimes :)
2. Using Kerberos in Win2k should work, as long as any Unix Kerb5 servers are slaves to the 2k server. From my reading, any attempt to use the AD LDAP for anything else is doomed to failure. Microsoft is supporting heterogeneous environments only to the extent that it moves people to their software, so they won't make it easy to maintain support of Unix systems.
3. If you're given your own Organizational Unit within the active directory, you can choose to block inheritance of permissions and policies and whatnot, and maintain a certain level of autonomy.
5. We've been going through the preliminary planning of rolling out AD in our mixed environment(NT, Solaris, Netware), and while it's been ugly, it doesn't seem hopeless. Services for Unix 2 promises a lot (password sync among them), and if it can deliver, then integration becomes that much easier. Just keep in mind that any Microsoft solution is offerred with the intention of burying your Unix boxes.
You fail to realize that that's as inevitable as death in most organizations.
...And as pleasant a thought.
Win2K is a fine gaming platform. Multiprocessor support and DirectX for games that don't run in an OpenGL mode. It has no other good uses. There is a better alternative for every other task you might want to do with a computer.
The only way to truly satisfy yourself is to setup a test environment. (To /.ers: please don't go on about "satisfying yourself" too much)
pi=sigma{n:0-infinity}[(1/16)^n][(4/(8n+1))-(2/(8n +4))-(1/ (8n+5))-(1/(8n+6))]
It is a great article seperate from problems with win2k.
Leknor
http://Leknor.com
Leknor
http://Leknor.com
"So many idiots, so few comets"
An old one.
An older one.
Some old benchmarks.
BTW sales of Win2K have been abysmal. A fact you don't hear much about, but which lies behind some of Microsoft's actions. (Trying to squeeze more revenue from existing streams.) Go out and look for yourself for some links on that (unfortunately not well enough publicized) story.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
And therein lies the problem. Management need to be made forcefully aware that the agency is not a Windows only shop, and that proposing Windows only solutions like this is a road to ruin. Sure, you may only be a minority, but they need to know that you cannot integrate with their solution without (at the very least) significant work. The need to know what the impact of alienating your department will be on the agency as a whole. Like it or not, management are stupid. Sure there are a few exceptions, but on the whole, it's a good approximation. I once worked at a company where management decreed that all corporate email should be handled by exchange and outlook. Only after buying the servers, and doing an initial roll out to some PCs did they realise that 30% of the desktops ran SunOS or Solaris on Sparc hardware... Management don't understand technological issues like these, and they need to have them explained.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
There is interesting technology in Active Directory. It is an interesting project to attempt to provide these services without requiring the use of a Windows 2000 server infrastructure. I can't say I'm doing an awful lot to help in this regard presently, but I've made some notes, and you can check them out at http://www.padl.com/~lukeh/XAD/whit e_paper.html. The SAMBA people are probably most active on this front.
To answer some of your questions: I believe W2K can access old SMB-style shares. After all, it wouldn't make sense for it not to work with NT 4 shares. I expect the "new" SMB is wrapped in the Kerberos SSPI (wire-compatible with the Kerberos GSS-API mechanism). Regarding storing RFC 2307 information AD, good luck. Microsoft have made some modifications to the schema in order to support various "features" of Active Directory, such as the lack of support for multi-valued naming attributes, auxiliary classes not being listed as values of the objectClass attribute, some attribute type conflicts with RFC 2307, etc. Microsoft have an "embraced and extended" version that ships with Services for UNIX, but this isn't plug-and-play with existing RFC 2307 clients unless they support on-the-fly attribute mapping.
I don't know about the issue of AD networked stations not being able to access NT4 style shares but I see no reason why they shouldn't
;)
What I DO KNOW is that the active directory can be run in 2 modes: native and mixed. In native mode it will of course deny anything that is not active directory compatible. In mixed mode it's supposed to let you work with older NT stations and servers/domain controllers. (Of course there are some features that require native mode to help force you a bit more towards it and once you're in native mode you can't go back to mixed either
About authentication, you'll have to check whether your Kerberos implementation is compatible to the one Microsoft is using and you'll also have to see whether your systems support the SVC records inside DNS. (Here are some RFCs that they refer to: RR records RFC2052, Dynamic DNS update RFC2136/RFC2137)
As for accessing data that is in the AD you'll have to figure out how to do it via LDAP I suppose.
Hope the above helps a bit. Unfortunately I'm no expert in these matters.
cough*OpenLDAP*cough*
Insightful?!
Did you read what bob was asking? Let me snip the bit so it's easy for you: "...we had been investigating doing something with Kerberos and OpenLDAP before this came up -- but the point is that the direction here is likely to be totally beyond our control.."
So, um, OpenLDAP is great and all, but he's talking about SOMEONE ELSE deploying AD and he has to adapt to it.
I've worked for way too many goverment groups in the past and the best advice was from a water engineer at the soil conservation survice.
The goverment works like a large bolder rolling down the hill. You can't stop it but you can change its direction if you push it at the right time and place.
Years ago I used this while working for DISA (DIMA's parent, they control the IT for the AF, as well as the Army, Navy etc in theory). DISA had decided that GOSIP email was the one true way and nothing was going to change that. Ok fine. Its a messed up version of X400 based on some of the worst code I have ever seen. I attended lots of meetings where lots was discussed but nothing was ever done. At the time I managed a large email system that involved some 87,000 users over 12 main systems. It was the largest system of its kind in the goverment. From what I had learned while working at SCS, I did the only reasonable thing which was to ask a Col if I could make a change to the propsed migration document. I changed one line to allow both X.400 migration system as well as SMTP migration. That got included in the main document, which became the long term plan and now thanks to cut and past into other docs, fully allows SMTP as valid part of the GOSSIP systems.
One edit and I killed X.400. Not bad for goverment work.
To address issue #1:
I am the administrator for a computer science lab that has workstations that dual-boot Windows 2000 Professional and RedHat Linux 6.2. I run two servers in the lab: Win 2000 Server and RedHat Linux 6.1. The Linux server exports its home directories via both NFS and Samba. The Windows 2000 Professional workstations are able to connect to Samba shares on the Linux server without any difficulties.
The Windows 2000 Professional workstations are also able to connect to shares on NT 4 servers.
Hope this helps.
Although it reads a little bit like a pro-Netware column, the article at: http://www.novell.com/competiti ve/nds/security.html gives specific steps (with pictures) on how to exploit ADS to gain access to sensitive information in a branch below you.
Hope it helps.
"Although I am no longer needed, I am still tolerated. I am deprecated." -.DM.
From the MS ADSI website
Getting and Using ADSI Providers
The standard Active Directory Service Interfaces objects, or providers, are found within multiple namespaces, typically directory services for various network operating systems. Providers enable communication between the server or client. ADSI 2.5 includes providers for:
And the real solution to the problem is getting someone to write an ADSI provider for Linux. So if you are inclined, HERES THE DEVELOPER KIT.
Or, Download someone else's provider HERE or HERE