Security

Ask something
Discussion Locked

authenticate users in mix environment

0 helpful
22 replies

by shanghai sam

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We have in the organization win2k domain ,and several linux (redhat 7.2) servers .
we have many users who are using both windows and
linux systems .we want to centrelize the
authentication so one system (windows d.c) will validate users usingkerberos when they login to linux.
my question is
1.is it possible to do such a thing if yes please
be very detaild about it.

22 replies

by maxwell edison

Kerberos was originally developed for use in the Athena cluster at MIT, and is in use there. The MIT implementation of Kerberos is distributed with Kerberized versions of the rlogin, rsh, telnet, and POP. Windows 2000 can use Kerberos for login and management of domains, and the Kerberos protocol was actually extended so that this could happen.

Red Hat Linux ships with Kerberos available.

Other applications which support Kerberos include CyberSafe ActiveTrust, ssh, CVS, Cyrus IMAP server, the Andrew File System, and Netatalk. Support for Kerberos is still limited and very few applications, mainly only the previously listed ones, use it.

----------

The system is built around the Needham and Schroeder authentication protocol, with slight modification for practical use.

The protocol begins with the user obtaining a Ticket Granting Ticket:

1. The user requests a Ticket Granting Ticket (TGT) from the Authentication Server (AS), sending her name and name of the TGS she wishes to use.

2. The AS generates a session key (Kerberos v4 uses DES) to be used between the user and the TGS, and encrypts it with the user's key (usually a password). The AS also creates a TGT for the user to authenticate themselves tothe TGS, and encrypts this with the TGS's secret key (this key is was generated and distributed securely, most likely using a physical method).

3. The user then unlocks the encrypted session key and now has a piece of identifying information and a means by which to communicate this with the TGS.

(continued..)

by maxwell edison

The password is necessary to unlock the TGT, so only the correct user can get the actual ticket. The ticket itself consists of the ID and network address of the user and the ID of the TGS. Additionally, the ticket contains a timestamp making it valid only for a certain amount of time. The ticket is also encrypted with a secret key known only by the TGS and the AS so it cannot be altered by the user.

When the user wishes to use a network service, she requests a service ticket from the TGS:

1. When the user needs authenticate themselves to a server, the user uses the TGT to authenticate themselves to the TGS and get a service ticket. The client sends the TGS the TGT and the authenticator.

2. The TGS decrypts the ticket with thesecret key, and gets the session key. It then uses the session key to decrypt the authenticator. The information in the authenticator is then verified and if valid, the TGS proceeds. (On of the important features here is the verification of the timestamp to prevent replay attacks.)

3. If the user is allowed to use the indicated service (the access controls are kept in a database of some sort), the TGS issues a service granting ticket which the user can use to authenticate themselves to theservice or server they want to use, and a session key for the user and service to use.

The user can then authenticate themselves to the desired service:

(continued..)

by maxwell edison

1. The user sends the service ticket to the server with the authenticator. Like the TGT, the session ticket contains a timestamp with lifetime and is encrypted to prevent alteration.

2. The server decrypts the service ticket with the secret key. They then decrypt the authenticator and verify that the user is who they say they according to the AS.

3. If the server also needs to be authenticated to the client, then it can send the client back a message encrypted with the session key, toprove they know it.

4. The user and server are now authenticated.

The preceding was obtained from a very detailed article on the subject. You may find the whole article very useful and informative as well as interesting.

http://www.cs.virginia.edu/~pev5b/writing/academic/kerberos.html

(REMOVE SPACES from the pasted URL.)

Maxwell

by joseph moore

Personally, I have never done this, but it can be done.
Microsoft Services for UNIX (SFU) is what you need. It works with Linux also.

First, here is the URL to the Windows Interoperability web site:http://www.microsoft.com/windows2000/interop/
This should be your starting point on how and why. There are lots of white papers to read on how to make Win2K and Linux work together.

Here is a quote from one of them:
"Reduce system administration time with tools that centralize network management across UNIX and Windows platforms, such as the Two-way Password Synchronization and Server for NIS components"

If you want to read a press release from Microsoft on "Introduction to Migration and Interoperability: Using Windows 2000 in a Mixed Environment" then go here:
http://www.microsoft.com/Windows2000/server/evaluation/business/interopsol.asp
(please remove any spaces)

Last but most important, the Services for UNIX web site:
http://www.microsoft.com/windows/sfu/default.asp

You will NEED to go here to look around for documents on how to set it up and integrate the authentication together.

by joseph moore

There are also a few Technet articles of interest, with some specifications you should look at. This is an important one:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q258855
(please remove any spaces)

Basically it looks like it willwork. Just install SFU, configure some files on the Linux boxes, and away you go. Client accounts get replicated between Win2K and Linux and vica versa. Apparently, you can eventually just use the Win2K AD Users & Computers snap-in to manange accounts on the Linux boxes!

hope this helps

by maxwell edison

I found another article, perhaps useful to you. It includes:

"It is expected that different administrative organizations will want to use Kerberos for user authentication. It is also expected that in many cases, users in one organization will want to use services in another. Kerberos supports multiple administrative domains. The specification of names in Kerberos includes a field called the realm. This field contains the name of the administrative domain within which the user is to be authenticated.
Services are usually registered in a single realm and will only accept credentials issued by an authentication server for that realm. A user is usually registered in a single realm (the local realm), but it is possible for her/him to obtain credentials issued by another realm (the remote realm), on the strength of the authentication provided by the local realm. Credentials valid in a remote realm indicate the realm in which the user was originally authenticated. Services in the remoterealm can choose whether to honor those credentials, depending on the degree of security required and the level of trust in the realm that initially authenticated the user.

In order to perform cross-realm authentication, it is necessary that theadministrators of each pair of realms select a key to be shared between their realms. A user in the local realm can then request a ticket-granting ticket from the local authentication server for the ticket-granting server in the remote realm. When that ticket is used, the remote ticket-granting server recognizes that the request is not from its own realm, and it uses the previously exchanged key to decrypt the ticket-granting ticket. It then issues a ticket as it normally would, except that therealm field for the client contains the name of the realm in which the client was originally authenticated."

(continued..)

by maxwell edison

(continued..)

"This approach could be extended to allow one to authenticate oneself through a series of realms until reaching the realm with the desired service. In order to do this, though, it would be necessary to record the entire path that was taken, and not just the name of the initial realm in which the user was authenticated. In such a situation, all that is known by the server is that A says that B says that C says that the user is so-and-so. This statement can only be trusted if everyone along the path is also trusted."

http://www.cisco.com/warp/public/106/2.html#Kerberi

http://www.cisco.com/warp/public/106/1.html

(REMOVE SPACES from the pasted URLs.)

Maxwell

by dlafrombois

Use a product like Novell Authenticate. It places a gadget or serice on each server which wil redirect the Authentication traffic to a single or clustered authentication database, in this case NDS or edirectory. It does not alter anything except how it authenticates. The users are still created on each box with the appropriate rights. If the user does not exist on the authentication server, then it checks the local authentication database on the server.

I am positive if a company like Novell can accomplish this then someone like Microsoft can.

by jose mir

See Novell eDirectory product: http://www.novell.com/products/edirectory/
No, it does not use kerberos, but you will be surprised with the new administrative way your mixed environment network will have.

To dlafrombois@hotmail.com : Don’t worry, Microsoft will, sooner or later, develop a product like eDirectory to replace it’s Active Directory. It will only takes some time until Mr. Gates surprise us with such a product or service; I personally think it will not take more than4 to 6 years (ok, maybe 10).

Jose P. Mir
jpm@jpmir.net

by jose mir

Note: I don’t sell Novell products, and I am not a ABM (anything but Microsoft) Linux lover. To tell you the truth I think that the big problem with Novell is it’s continuous mismanagement (because, for many reasons, I don’t think Novell has ever had managers; starting with Mr. Norda). It looks like this company has learned only the wrong IBM lessons.

Jose P. Mir
jpm@jpmir.net

by catmanth

I use normally the SAMBA system on Linux for handle this. Samba you can configure to verify the username and password against a Window NT / Windows 2000 server. But in this case the windows user have only access to the samba file system

by alpha-male

How about we close this question in the Tech Republic environment and give someone else a chance on the featured questions list?

by techies

Hi

This is possible by having samba/winbind service running on linux servers.

Winbind allows linux systems to join winnt/2000 domain and act as BDC

Users can login normally on linux systems whereas authentication mechanism will be providedby windows d.c.

Winbind is free and ships with redhat 7.2 onwards
or can be downloaded from samba or redhat site

Rgds
Yukthi Systems Pvt Ltd
www.yukthi.com

by servermonkey

Novell Account Management 3.0. Works with Linux, Solaris, HP-UX, etc and Win32.

No Netware server required.

This discussion is closed to new replies.