I do feel that your documents provide this, yes. However, at last look they were under a restrictive licence for use (you have to register with your site, and you have to agree to provide feedback) meaning that some people may not be able to use them.

The offer that I made to arkus applies to anyone who wants to publish these instructions under a non-restrictive licence, including yourself. If you could expand these to include a straight LDAP authentication solution without the need for Winbind on all servers, I will consider increasing my contribution offer.

I know that the amounts I am talking about seem small, but with the amount of people asking for this information, I'm hoping that other people will be willing to contribute as well to make the effort worth it.

I know what it's like to write documentation and maintain it for free - it's a largely thankless and unglamourous job. Fortunately, the documents that I have done regarding Free software are un-related to my consulting work, and as such I am able to publish with no restrictions from outside parties.

I'm not so concerned about the dollar figure that you are discussing. It would be welcome, obviously, and I would love to work with you and the community to optimize the documents. I know that if I was able to obtain some of this assistance, I would be able to take care of the rest.

My problem is, that I have to be able to provide SOME value back to my organization. As of right now, I receive no monetary benefit (which isn't necessarily a problem), which is why I've been looking to have registration and/or feedback on the documents. This gives me a handle on who is using them. that too, is value to me.

Hello there... I am in desperae need of a document like this... I have gone to the site and registered, though the document being discussed is not available.. or not found rather... Please point me ina direction by which I could find this...

I am trying to join a Windows 2000 Active Directory structure with RHEL 3 and/or RHEL 4 beta

Most of the AD<->Linux solutions involve the SFU (Services for Unix) from Microsoft. This usually involves applying a schema update from that package to the AD LDAP and often (but not always) running the SFU NIS services.

There is the Samba Winbind route which will become more funtional with the next interim release of Samba (3.2) before 4.0 comes out.... and 4.0 will supposedly work even better.

On the cheap... use Samba and the login script under Windows.

1. When Windows users login, attempt to mount your Unix/Linux home directory.... where that directory is available via Samba.

2. Samba can be configured to kick off a script if the user does not exist when a share is accessed... use that to create the user (it can work off a list of users allowed if you want some security). Use that script to create the user and home dir.

4. Create a putty key on the Windows side and stick the key into the home dir side... which will now exist if you did #2 acceptably.

5. Load the key on the Windows side via the putty agent for Windows allowing the user to bring up windows to any of the Linux/Unix hosts without using a password.

When you are done, you'll be able to log into the domain under a Windows client and log into the Unix/Linux hosts from that client using PuTTY without having to reauthenticate.

Combine this with running winbindd on the Unix/Linux hosts and then you can log in directly (outside of using the Windows client) using your id... which will authenticate with a AD password server.

You may have to have the script in #2 generate a scrap password or some things might fail (some things look for a password being present on the Unix/Linux box even if it's not used for authentication... for account validity).

I know this isn't a detailed cookbook... eventually I may write something up and post it.... and surprise, surprise, I won't charge anything!

I think your missing the point... we are not trying to login to a linux/unix box under windows... we want to add linux as an AD client... equivalent to what a windows 2000 Pro or XP pro box would be to a W2K Server....

We want authentication on the linux box FROM a Windows 2000/2003 Server Active Directory listing...

Once you have logged into the site, the documents are under LanRx Solutions.
You will have to login with your username and password on the right hand side of the screen.

Then when you go go the LanRx solutions section, you will see the documents there.

Edited to add: And you have not been charged for access to these documents, either!

I don't think I'm missing the point. My solution gives you complete secure, single sign-on from a AD DOMAIN (I suggest you re-read my post). It does it simply without having to rely so heavily on Microsoft's ever changing rpc's.

With the solution I have outline you can access any Unix/Linux host without reauthenticating from your Windows client AND (if you had read the whole thing) you can log in directly from the Unix/Linux console head if you have windbind configured.

I have already implemented this solution at a large manufacturing company. Since the majority of the users have Windows desktops, they simply PuTTY into the Linux hosts WITHOUT having to type in a password every time. I (and a few others not authenticating via a Windows client) can login directly into the Linux hosts by typing our AD password (once logged into a host, we can use the same SSH key technique as used by the Windows hosts to avoid having to authenticate to hosts we reach from our non-Windows client).

Which is fine, as long as you're not running samba services on the device as well. Because if you are, then your UID/GID can be different if coming in from a prompt or over a CIFS share.

Sigh... you can map ids to local ids if they match via winbindd. So not a problem.

It would just seem to me, that you would want your administration to be as centralized as possible. And if you're having to map things locally, then that kind of defeats the purpose.

good infos u guys, i will make a research about these;

Administration is COMPLETELY localized. Create the user on the AD machine and single sign on everywhere.

umm.. cjcox...

If your creating the user on the AD server.. and they sign on everywhere else.. than that is centralized.. not localized...

And the point is to try and get linux to recognize and authenticate via Active Directory... so if you have to create the name in AD and then create the local machine account.. it defeats the purpose.. that's what we are saying..

The system AUTOMATICALLY creates the accounts for the *ix boxes. Password authentication is via the Windows password server.

You DON'T create anything BUT the Windows account. Then you can log in from ANYWHERE (from the console, from a client, whatever) into the *ix hosts. As long as you are authenticated to a trusted client (Windows or *ix), you can pull up a shell onto any *ix host without using a password. A trusted client in *ix is simply one where your ssh keys are have been authorized for use. You can always login directly into the *ix hosts supplying your AD password if you are coming in from a client where your keys are not enabled.

Remember, this isn't theory here... this is in production today.

Now there is a replication of account data, AD and *ix (LDAP or NIS). But the passwords are always authentiated via AD, so if the account is disabled or removed in Windows, you won't easily get into the *ix areas as that user (you'd
need root or a back door or some other non-password/key auth path).

It's not perfect... we don't allow password changes from the *ix side, you have to change your passwords from a Windows authenticated client, but those things can be added, arguably with less than valuable benefit for the work involved.