Active Directory/Documentation/What is SFU?

From WolfTech
Revision as of 17:08, 5 May 2008 by Djgreen (talk | contribs) (New page: ==What is it?== UNIX–based and Windows–based operating systems use different directories and access control mechanisms. Because the two systems use different authentication mechanisms,...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

What is it?

UNIX–based and Windows–based operating systems use different directories and access control mechanisms. Because the two systems use different authentication mechanisms, users have separate user identities for each system, even when their user names appear identical (aka the fact that my WolfTechID ‘djgreen’, while looking the same, isn’t my UnityID ‘djgreen’). These different identities and their separate passwords are a problem for both users and administrators. In a logical enterprise network, users have a single sign-on mechanism to access resources transparently on both systems. Access to resources on UNIX from a Windows–based computer, or vice versa, requires separate authentication. Consequently, the network is split into disjointed Windows–based and UNIX–based domains, creating an artificial barrier that divides a single enterprise network.

Microsoft Windows Services for UNIX (SFU) 3.5 allows Windows–based and UNIX–based computers to share data, security credentials, and scripts. It is used by Administrators looking for solutions to integrate a heterogeneous network and share information seamlessly between their Windows and UNIX systems.

Technically, we’ll be installing “Identity Management for UNIX”, its new name since Server 2003 R2.

Specifically, why do we need it?

  1. ITECS would like to authenticate a Solaris 10 client against the WolfTech Active Directory. To do so requires this installation plus a number of scripts on the client (the client side steps will be documented in the wiki once they’ve been proven to work).
  2. Linux integration step – Adding these services to the domain has been on my to-do list for a while. It has been my hopes that this, combined with a trust of the NCSU MIT KDC and using a process known as “shadow accounts”, would allow for file and print requests from campus RHEL boxes to be correctly recognized and authenticated, closing a few security holes (currently, if you want a Windows print server to listen to a Linux lpr client, you need to allow “Everyone” to use it). This installation is the first of a few steps down this path.

Why am I mentioning it?

  1. Schema change – SFU does require a schema extension so it can support the POSIX schema in Active Directory.
  2. New tab in User/Computer objects – once installed, an additional tab, “UNIX Attributes”, may be seen on User and Computer objects when managing their properties. I would ask that everyone ignore this tab while we get this all figured out.