Windows 2000 Directory Support While Keeping Unix?

bob asks: "I work for an idependant agency of the US goverment. My group supports about 350 people, or about 20% of the agency's staff. Most of our users spend their days crunching enormous piles of numbers, calculating models, simulations, projections and other scientific type stuff. We were strictly a Unix (with some mainframe) shop from about 1985-1995, when agency- (and industry-for that matter) wide "standards" forced us to implement NT desktop machines so our people could run things like MS Office and PeopleSoft.However, with a bunch of work and with extensive use of various tools like Samba and Hummingbird's eXceed, we were able to make this change without significant damage to our Unix environment. In fact, this has been working pretty smoothly and we had begun to evaluate the practicality of replacing most of our NT servers with Linux machines, contingent on the Samba ACL code reaching a reasonable level of stability. Sadly, we now are faced with what, on first glance, would appear to be a larger threat: Active Directory."

"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:

1. 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.
2. 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?
3. 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?
4. 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?
5. 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."

Comments

A couple of things

[jackmama]

It's mighty early in the morning, so I won't try to tackle all the questions, just these that jumped out at me:

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.

Re:A couple of things

[swb]

It's possible, but how often does it get done in NDS? One of the first things they tell you in NDS class is BE CAREFULL WHEN YOU DO THIS. If you delegate authority to an OU and that OU blocks out administrative inheritence you are sorely fsck'd, because you now have an OU that's unmanageable and potentially a whole huge NDS mess.

What I do is delegate authority to an Organizational Role, add the OU admin and the other higher-level admins to the OrgRole, and then grant the NDS rights to the OrgRole. The key thing here is to create the OrgRole above the OU in question so that you can't be blocked out.

Blocking higher level admins is a nice ability, but unless you have 100% trust in your downstream admins you can end up causing more problems than solutions. When I took NDS classes, the instructor spent a good deal of time recounting examples from the consulting side of the education company's business of when this had gone sorely wrong -- high level OUs with hundreds of users and other objects left unmanagable.

What lots of big organizations that want autonomy do is create seperate trees. The downside to doing this is that there's no way to create trust relationships between trees, which I think is a failing (along with the inability to make OUs a member of a group..).

-NDS user

Re:A couple of things

[T-Ranger]

The whole idea of directory services is to combine everything into a single repository, everything potentialy expanding well beyond just information for access to computer resources. Consiter scheduling, electronic locks, HR thingers. Consiter a university whos accademic scheduling software can push down information to NDS so registering for a class gives you access to that special printer. Integration with PBXs. And on and on. 'Directories' are not just for convient computer administration, there for convient everything. Give meeting rooms and slide projectors entries in your directory, and 'invite' them to meetings.

Whatever: the point is you want everything in a directory, and you want everything in a single directory.

However lets say, there is some kind of realy top secret group, or project or something - new products or a security force, or internal affairs in a police department. Now, you've set up NDS either physcialy, or logicly, but either way there are things that are defined in a higher level that you want to flow down. Everybody gets Netscape in ZEN, everybody in bldg 17 gets access to some printer. However, since this paricular group is anal about security, they want there own container admin, and dont want higher level admin's inhereting rights. Your buliding admin can still define ZEN profiles, and printers (and groupwise routing rules, and......) but they dont have access to the sensitive information in that container.

So you can have it both ways, a single direcrory, with inhereted profiles for (whatever), and a secure container.

NDS has been around for 7 years. Its proven to work, and proven to work with insanly large trees. ADS is brand spanking new, unproven, and built on flaky grounds (it runs on JET - the DB backend desigined for Access). ADS runs on Windows. NDS runs on Netware, NT, win2k, solaris, linux, AIX, OS/390, and Tru64.

NDS - ADS comparision ADS runs on Windows. NDS runs on Netware, NT, win2k, solaris, linux, AIX, OS/390, and Tru64.

Re:Kerberos and LDAP

[bukys]

No, Microsoft has embraced and extended Kerberos: you can use a W2K Kerberos server with both Unix and Windows clients. You can't use a non-Microsoft Kerberos server and support the extra Microsoft baggage for W2K clients. (Baggage recently documented by Microsoft, under non-disclosure.)

See http://slashdot.org/articles/00/06/28/0042228.shtm l for recent SlashDot discussion.

I don't know the details but their are problems

[Citrix]

I wish I had more info for you but all I could dig up from recent memory was this article that references probelsm IBM and MIT have had with Win2k: http://www.funky-pengu in.co.uk/index.php?zone=articles&id=13

It is a great article seperate from problems with win2k.
Leknor
http://Leknor.com

The only solution is to educate management

[Tet]

but the point is that the direction here is likely to be totally beyond our control

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.

AD native or compatible ...

[Lev_Arris]

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.

How to deal with the goverment

[thogard]

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.