Posted by arlene

In Version 1 of SFU, the password synchronization feature enabled you to configure a group of Unix servers so that when a user’s password was changed on a Windows NT server, the change was propagated to the user’s accounts on those target Unix servers. Because the application ran only on the Windows NT computer, it was a one-way service. That is, changes made on the Unix servers were not sent back to the Windows NT computer.

Versions 2 and 3 of SFU now make this functionality a two-way street. To use this SFU component, you’ll need to load the Password Synchronization service on the Windows Server (or NT) and, additionally, you’ll have to run a daemon (called a Single Sign-On Daemon, or SSOD for short) on each Unix box that will participate in the password-update process. SFU Version 3.5 comes with versions of the daemon that have been compiled for the following variants of Unix:

• HP-UX 1 li
• Sun Solaris 7, 8
• IBM AIX 5L 5.2
• Red Hat Linux

However, if your Unix isn’t in this list, you can still use the synchronization daemon. SFU comes with the source code and makefiles that you can use to compile a version for your particular system. The SSOD daemon is the background process that receives password changes from Windows computers. Another program, called the Password Authentication Manager (PAM), is used on the Unix server to send password changes made on the Unix system to Windows systems.

There are a few things about the synchronization process to consider before you deploy this service in your network. First, if your Windows computers are participating in a domain, you’ll have to run the service on all the domain controllers in that domain. If you use Windows NT or Windows 2000 in a workgroup (or simply as standalone computers), you’ll have to run the service on each computer if you want the passwords to stay synchronized among all the Windows computers.

Note

Although most large Windows NT and Windows Server networks use the Active Directory to make managing network users, computers, and resources an easier task, you can still run Windows NT/2000/2003 as standalone computers. In that situation, each computer stores user and computer account information locally instead of in the Active Directory. That’s why you must run the Password Synchronization service on each Windows computer if you don’t use a domain or an Active Directory model for your network. Each computer must be capable of receiving password changes and applying them to the local database. In a domain-based environment, where users log on to the domain, only the domain controllers need to run the service.

Another caveat you must keep in mind is that Unix account names and passwords are case sensitive. Therefore, you’ll have to create accounts on your Windows and Unix systems that are exactly the same. If you already have accounts set up in your network that have users with different account names on different systems, you’ll have to pick a single account name for the user and then re-create the account on each computer so that they all match.

Finally, in addition to providing the capability to synchronize passwords between the Windows systems and those that are stored on individual Unix computers (in the / et c /pas swd file, for example), you also can synchronize passwords with Unix networks that use the Network Information Service(NIS). Just install the SSOD on a master NIS or NIS+ server.

User Name Mapping

If you have an environment in which users already have accounts on both Unix and Windows servers that aren’t the same, SFU provides a component that can be used to map the different user- names. You can map usernames in a one-to-one manner or in a one-to-many manner. For example, you can create an entry that maps the name tog let ree to TOGLETR EE. Or if you want the user to be able to access multiple user accounts, you can map the user’s account name to several different account names. This second feature proves very useful if you have an assortment of Unix servers and each server has a different name used for an administrative account. You can map a single Windows user account name to each of the user accounts on the various Unix servers. Or you can use this multiple-mapping feature to map the typical Unix account called root to more than one Windows administrative account.

The advantages of multiple mappings might not seem very intuitive at first, but let’s consider an example. Suppose that you want to enable the Unix administrator in your network to manage some, but not all, of your Windows-based systems. You can create a user account on each Windows computer and grant it the necessary rights and permissions. Then map the root account to these new account names. That way you don’t have to simply map root to Administrator, which would give access to all computers in the domain.

One final note about username mapping: It isn’t a substitute for password synchronization. Remember that password synchronization, discussed in the previous section, requires that user account names be exactly the same on the computers that are participating in the synchronization process. User Name Mapping is simply another tool you can use to manage users who have accounts on both systems. If you’re creating a network from scratch or if you can easily create user accounts on all of your systems that are the same, you probably won’t need to use User Name Mapping and simply can let the users have a single account name on all systems, keeping passwords synchronized. Password synchronization will not work to synchronize passwords for accounts that are linked using User Name Mapping!

Possibly related posts: (automatically generated)
Password Synchronization

• Replication Between Domain Controllers
• Microsoft Directory Synchronization Services (MSDSS) continue...
• Microsoft Directory Synchronization Services (MSDSS)
• Website Hosting Sever, some Pitfalls you need to avoid part 1
• Using the DTS Wizard to Reload Our SQLSpyNet
• Improving Security
• Unix and Linux User Administration
• Network and Servers Technical Compare continue...
• Connecting to SQL Server 2000 for the First Time
• Local Vulnerabilities