fedora core 1 and win2k domain

[phishphreek]

I've been using linux at home for quite some time now. I don't have a domain at home, just a workgroup with mixed OSs. XP, 2K, RH, SuSE, etc.

I installed a Fedora Core 1 box and set it all up security wise.

I want to bring it into work to show my boss some of the cababilities of Linux.
He is very pro m$ and never really messed with linux. He tried to muck with RH 6.2, but he gave up..

I would like to join it to the Win2K domain and authenticate with the domain via active directory.
It is a mixed mode domain (NT4 (only one left) and 2K). Soon to be in native mode... probably within the next couple of weeks. The NT4 server is no longer needed and we just haven't gotten around to swithing to native mode.

How can I go about doing this?

I did a couple quick searches, but didn't come up with enough. Most of the info I've come up with has to do with setting up a Linux box on a Win2K domain and using the Win2K active directory as the authentication method for samba. I'm good on that. I need help actually logging it into the domain to use network printers and other resouces. In other words, on a m$ box, it'll come up at login screen

UID
PWD
Domain

How can I set this on linux?
I don't want to log in locally with local usernames. I want to use usernames in active directory.

I figured the experts at AO would be a better resource.

Any help is appreciated!

Thanks in advance!

[phishphreek]

Just found http://www.securityfocus.com/infocus/1563 ... would this work? I haven't yet had a chance to try it out.

[slarty]

I can't tell you exactly what you need to do, but it basically boils down to something like this:

- Install samba - because you're going to use parts of it. Join Samba to the domain in the normal way.

- set up winbindd from samba (a daemon which does authentication) - This is a daemon which takes requests from local processes and forwards them to the domain controller (I think)
- set up pam_winbindd or whatever it's called - This is a pluggable authentication module which uses a windows domain. This actually lets users log on.
- set up nss_winbindd - this is the "name service switch" module. Basically it's the thing which makes ls -l and other commands which aren't to do with authentication per se, but need to map users to uids and vice versa.

What I'm not 100% sure about is how unix user IDs get allocated to Windows users. Originally, you needed to have an entry for them in /etc/passwd. However, this should not now be necessary.

With a samba domain controller, it has its own mapping of unix user IDs for Windows users.

Anyway, some or all of these steps may be automated. Or you might need to do them manually. Anyway it'd be an interesting venture.

You can potentially get problems with usernames / passwords which aren't understood by Unix (i.e. those which contain extended characters) - the easiest solution is to not use them.

So you should have your username policy such that usernames are compatible with Unix. In practice this means

- Hopefully less than 8 characters long (maybe longer would work on some systems, but gets truncated in ls -l and stuff)
- containing only letters, numbers and possibly a few other things like dots
- Lowercase for preference
- Not starting with a digit

The common NT practice of firstname.lastname may work although sometimes exceeds the reasonable length.

Slarty

[phishphreek]

Thanks slarty. I'll have to mess with that a bit.

I've found that I can do it similar to how I do at home.

Keep the local linux userid and password the same as what is on the network.

It doesn't give me everything I need... but its a start. I just want this for a "demo" really...

Thanks again!

[slarty]

I suppose there are two basic approaches:

1. Use NT domains for authentication only
2. Use NT domains for all user DB information

The first one is pretty straightforward to achieve and I've had it working nicely.

The second is potentially much more problematic, as you need to have some way to associate Unix-specific user information with your NT users (user ID, group IDs, and home directory at least).

Of course to truly obtain a zero-additional user admin system , you need to achieve the 2nd, so that users can seamlessly access Unix boxes.

There are a number of slightly nasty halfway houses, than involve keeping local (Unix) copies of the information, and inventing it algorithmically if an unknown user attempts to log on. This is however problematic, as there's then no way of synchronising this info between multiple Unix boxes (for NFS for example)

Slarty