As most people who have been
in IT long enough to become enterprise administrators know, few
environments use products from a single vendor. Although products from a
single vendor generally work well with each other, it can be difficult
to integrate information technology products from different companies.
Part of an enterprise administrator’s job is to make the user experience
seamless. You need to ensure that a user who can access a set of shared
files on one server, when logged on to a computer running Windows Vista
with his or her Active Directory user account, can access exactly the
same set of shared files when logged on to a UNIX-based computer with
the same user account. In this lesson, you will learn how you can use
Windows Server 2008 to enable disparate technologies to interoperate. It
is your job as enterprise administrator to plan things so that the
workers in your environment need not be aware of the technical
complexities of the solution, only that they need to remember one
username and password to access the resources they need, irrespective of
the method they use to access those resources.
Planning AD FS
AD FS enables a
user from a partner organization to authenticate to multiple related Web
applications from a single sign-on without requiring a forest trust. AD
FS accomplishes this by securely sharing digital identity and
entitlement rights across a set of preconfigured security boundaries.
For example, AD FS enables you to configure a Web application on your
network to use a directory service on a trusted partner organization’s
network for authentication. AD FS enables user accounts from one
organization to access the applications of another organization while
still enabling full administrative control to each organization’s IT
departments. Rather than having to create a new account for a person
when you need to grant access to a Web application that you manage, you
trust the partner organization’s directory service. Users from the
partner organization can then authenticate to your organization’s Web
application, using their own organization’s credentials. Figure 1 displays the AD FS console.
AD
FS requires that one organization have deployed either AD DS or Active
Directory Lightweight Directory Services (AD LDS). Although AD FS was
available with Windows Server 2003 R2, the version of AD FS that is
included with Windows Server 2008 is more tightly integrated with
Microsoft Office SharePoint Services 2007 and Active Directory Rights
Management Services. Federation trusts are set up between organizations.
An AD FS deployment can include the following roles:
Federation Server role
A server that hosts the Federation Server role routes authentication
requests from user accounts in other organizations or from clients on
the Internet.
Federation Server Proxy role
Servers with the Federation Server Proxy role are often deployed on
screened subnets and forward authentication traffic to servers hosting
the Federation Server role from clients on the Internet. You cannot
deploy the Federation Server role service and the Federation Service
Proxy role service on the same computer.
Account Federation server
The Account Federation server is located on the network of the partner
organization and issues security tokens to the user that are then
forwarded to your organization’s server.
AD FS Web Agent
The AD FS Web Agent is software installed on a Web server that uses
security tokens signed by a valid federation server to allow or deny
access to a protected application.
AD FS–enabled Web servers
AD FS–enabled Web servers have the AD FS Web Agent installed. These
servers must be configured with a relationship to a Federation Server so
that authentication can occur.
One of the most
important aspects of AD FS is the level of trust that it requires you to
give your partner organization for the management of user accounts.
After you create a federated trust, you have to trust that your partner
organization is managing user accounts properly. If your partner
organization is diligent in the way it manages user accounts, this will
not pose any problems. If your partner organization is not so diligent,
problems could arise. For example, you might work for a manufacturing
organization that uses AD FS to allow its partner organizations to log
on to a sensitive inventory Web application. Competitor organizations
could derive
significant commercial benefit by accessing this inventory data.
Imagine that a user from the partner organization, who has had access to
the inventory Web application, decides to leave his or her job to work
for a competitor. If the partner organization is diligent, it will
disable the account. If the partner organization is not diligent, that
user still might have access to your organization’s sensitive data. With
AD FS, you have to trust that the partner organization will always
manage access to your organization’s applications diligently. For many
organizations, this can become a political problem. In planning an AD FS
strategy, you are likely to spend more time dealing with the political
aspects of enabling a partner organization to control access to your
organization’s Web applications than you are in putting together the
technical solution in the first place.
Microsoft Identity Lifecycle Manager 2007 Feature Pack 1
Identity Lifecycle
Manager (ILM) 2007 Feature Pack 1 (FP1) is a tool that enables
organizations to manage a single user’s identity across a heterogeneous
enterprise environment. The identity synchronization and user
provisioning component of ILM 2007 FP1 stores aggregate identity
information from multiple sources in a central repository called the metaverse.
Management agents installed on each source work as connectors,
translating identity information from connected sources to the
metaverse.
ILM 2007 FP1 can synchronize user identity data between Windows Server 2008 AD DS and the following products:
Active Directory on Windows Server 2003 R2, Windows Server 2003, and Windows 2000 Server
Active Directory Application Mode on Windows Server 2003 R2
Microsoft Windows NT 4.0 Domain
IBM Tivoli Directory Server
Novell eDirectory 8.6.2, 8.7, and 8.7.x
Sun Directory Server 4.x and 6.x
Exchange Server 2007, Exchange Server 2003, Exchange 2000 Server, and Exchange Server 5.5
Lotus Notes 7.0, 6.x, 5.0, and 4.6
SAP 5.0 and 4.7
Microsoft SQL Server 2005, SQL Server 2000, and SQL Server 7
IBM DB2
Oracle 10g, 9i, and 8i
ILM 2007 FP1 enables
organizations to integrate disparate identity systems. For example,
using ILM 2007 FP1, an organization could configure its Exchange Server
2007 deployment to link to the Human Resources
database. When an employee joins the organization and is added to this
database, ILM 2007 FP1 can be configured to set up that employee
automatically within Exchange Server 2007 or within any other messaging
system for which there is an ILM 2007 FP1 connector.
You can also use ILM 2007
FP1 to manage certificates and smart cards in an enterprise environment.
ILM 2007 FP1 integrates with AD DS and Active Directory Certificate
Services to provision digital certificates and smart cards directly.
You can install ILM
2007 FP1 on the Enterprise editions of Windows Server 2003 and Windows
Server 2008. ILM 2007 FP1 also needs access to a SQL Server 2008, SQL
Server 2005, or SQL Server 2000 database server.
Planning for UNIX Interoperability
As an enterprise
administrator, you are aware that many companies do not settle on a
single company’s operating system solutions for the clients and servers.
In some cases, your organization might choose an alternative solution
because it meets a particular set of needs at a particular point in
time; in other cases, you might inherit a diverse operating system
environment when your company acquires a subsidiary. In either
situation, it is your job as enterprise administrator to ensure that
these diverse systems interoperate in a seamless manner. Windows Server
2008 includes several features and role services that can assist in
integrating UNIX-based operating systems in a Windows Server 2008
network infrastructure.
Identity Management
Identity Management for UNIX
is a role service that enables you to integrate your Windows users in
existing environments that host UNIX-based computers. You are most
likely to deploy this feature in environments that are predominantly
UNIX based and where Windows users and computers running Windows must
integrate in an existing UNIX-based infrastructure. Identity Management
for UNIX is compatible with Internet Engineering Task Force (IETF)
Request for Comments (RFC) 2307, “An Approach for Using LDAP as a
Network Information Service.” A Lightweight Directory Access Protocol
(LDAP) server resolves network password and Network Information Service
(NIS) attribute requests. LDAP is a directory services protocol commonly
used in UNIX environments in a way very similar to how AD DS is used on
Windows networks.
Password Synchronization
The Password
Synchronization component of Identity Management for UNIX simplifies the
process of maintaining secure passwords in environments in which
computers running UNIX and Windows are present and used by staff.
Password synchronization is particularly important in environments in
which users need to log on regularly to computers running Windows and
UNIX. When Password Synchronization is deployed, the user’s password on
all UNIX computers in the environment will also be changed when a user
changes his or her password in AD DS. Similarly, you can configure the
Password Synchronization component to change a password automatically in
AD DS when a user’s UNIX password is changed. You configure the
direction of password synchronization by setting the password
synchronization properties as shown in Figure 2. You access the Password Synchronization Properties dialog box by using the Microsoft Identity Management for UNIX console.
Password synchronization is supported between Windows Server 2008 and the following UNIX-based operating systems:
Hewlett Packard HP UX 11i v1
IBM AIX version 5L 5.2 and 5L 5.3
Novel SUSE Linux Enterprise Server 10
Red Hat Enterprise Linux 4 Server
Sun Microsystems Solaris 10 (SPARC architecture only)
You should deploy Password
Synchronization on all DCs in a domain in which it is needed. Any newly
deployed DCs in the domain should also have this feature installed.
Microsoft also recommends that you demote a DC before removing Password
Synchronization. Ensure that the password policies on the UNIX computers
and within the Windows domain are similarly restrictive. Inconsistent
password policies will result in a synchronization failure if a user is
able to change a password on a less restrictive system because the
password will not be changed on the more restrictive system due to the
password policy. When configuring Password Synchronization, best
practice is to ensure that the passwords of sensitive accounts, such as
those of administrators from both UNIX and Windows environments, are not
replicated. By default, members of the local Windows Administrators and
Domain Administrators groups are not replicated.
Subsystem for UNIX-Based Applications
Subsystem for UNIX-based
Applications (SUA) is a Windows Server 2008 feature that enables
enterprises to run UNIX-based applications on computers running Windows
Server 2008. SUA provides a UNIX-like environment, including shells, a
set of scripting utilities, and a software development kit (SDK). SUA
also provides support for case-sensitive file names, compilation tools,
job control, and more than 300 popular UNIX utilities, commands, and
shell scripts. You can install Subsystem for UNIX-based Applications as a
Windows feature by using the Add Features Wizard.
A computer running Windows
Server 2008 that has the SUA feature installed enables two separate
command-line environments: a UNIX environment and a Windows environment.
Applications execute within a specific environment. A UNIX command
executes within the UNIX environment, and a Windows command executes
within the Windows environment. Although the environments are different,
commands executing in these environments can manipulate files stored on
Windows volumes normally. For example, you can use the UNIX-based grep command under SUA to search a text file stored on an NTFS volume.
UNIX
applications that run on existing computers can be ported to run on
Windows Server 2008 under the SUA subsystem. This enables organizations
to migrate existing applications that run on UNIX computers to Windows
Server 2008. SUA supports 64-bit applications running on a 64-bit
version of Windows Server 2008 as well as 32-bit applications running on
both the 64-bit and 32-bit versions of Windows Server 2008. SUA
supports connectivity to Oracle and SQL Server databases by using the
Oracle Call Interface (OCI) and Open Database Connectivity (ODBC)
standards. SUA also includes support that enables developers to debug
Portable Operating System Interface (POSIX) processes by using Microsoft
Visual Studio. POSIX is a collection of standards that define the
application programming interface (API) for software that is compatible
with UNIX-based operating systems.
Although it is
possible to run some UNIX-based operating systems under Hyper-V, many
UNIX computers use processor architectures other than x86 or x64. Only
operating systems that run on the x86 or x64 architectures are
compatible with Hyper-V. When planning the migration of POSIX-compliant
applications from UNIX-based computers to Windows Server 2008, first
determine whether the application can be migrated to run under the SUA
subsystem. If the application cannot be migrated, a virtualization
alternative might be necessary. In some cases, it will not be possible
to migrate a UNIX-based application to a Windows host or
a virtualized UNIX host running under Hyper-V. It is important that you
determine what is possible before you make any firm plans to
decommission existing UNIX-based computers.
Server for NIS
Server for NIS enables a
Windows Server 2008 DC to act as a master NIS server for one or more NIS
domains. Server for NIS provides a single namespace for NIS and Windows
domains that an enterprise administrator can manage by using a single
set of tools. Server for NIS stores the following NIS map data in AD DS:
aliases
bootparams
ethers
hosts
group
netgroup
netid
netmasks
networks
passwd
protocols
rpc
services
pservers
shadow
It is possible to deploy
Server for NIS on other DCs located in the same domain as the master NIS
server. This enables these DCs to function as NIS subordinate servers,
and NIS data is replicated through AD DS to the servers hosting the
Server for NIS role. UNIX-based computers can also function as NIS
subordinate servers because Server for NIS uses the same replication
protocol to propagate NIS data to UNIX-based subordinates as a
UNIX-based NIS master server does. When considering the deployment of
Server for NIS in an integrated environment, remember that a computer
running Windows Server 2008 must hold the master NIS server role. A
computer running Windows Server 2008 cannot function as an NIS
subordinate server to a UNIX-based NIS master.
When
planning the migration from UNIX-based NIS servers to Windows-based NIS
servers, your first task is to move the NIS maps to the new Windows
Server 2008 NIS server. After you do this, the computer running Windows
Server 2008 can function as an NIS master. It is possible to move
multiple NIS domains to a single Windows Server 2008 DC. Although you
can configure Server for NIS to support multiple NIS domains
concurrently, you can also merge the domains after they have been
migrated to the Windows Server 2008 DC running Server for NIS.
You are likely to plan
the deployment of Server for NIS when you want to retire an existing NIS
server infrastructure although NIS clients are still present on your
organizational network. Server for NIS enables you to consolidate your
server infrastructure around the Windows Server 2008 operating system
while enabling UNIX-based NIS client computers to continue functioning
normally on your organizational network.
When planning the
deployment of Server for NIS, remember that this component is installed
as a role service under the AD DS server role. Server for NIS can be
installed only on a Windows Server 2008 DC. You cannot deploy Server for
NIS on a standalone computer running Windows Server 2008 or on a member
server running Windows Server 2008.
Services for Network File System
Services for Network
File System (NFS) enables file sharing between Windows-based and
UNIX-based computers. Plan to deploy Services for NFS if your
environment contains a large number of UNIX-based client computers that
need to access the same shared files as the Windows-based client
computers on your organization’s network. Figure 3 shows the NFS Advanced Sharing dialog box on a computer running Windows Server 2008 configured with Services for NFS.
During the deployment
of Services for NFS, you must configure AD DS lookup resolution for
UNIX group ID and UNIX user ID (GID and UID). You do this by installing
the Identity Management for UNIX Active Directory schema extension that
is included in Windows Server 2008.You can then
configure identity mapping by configuring the properties of Services
for NFS and specifying the domain in the forest in which Identity
Management for UNIX has been installed. Figure 4 shows identity mapping configuration for Services for NFS.
