JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Identity Synchronization for Windows 6.0 Deployment Planning Guide
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Case Study: Deploying in a Multimaster Replication Environment

3.  Case Study: Deploying in a High-Availability Environment Over a Wide Area Network Using SSL

A.  Pluggable Authentication Modules

Overview

Configuring PAM and Identity Synchronization for Windows

Step 1: Configure an LDAP Repository for PAM

Step 2: Configuring Identity Synchronization for Windows

Step 3: Populating the LDAP Repository

Step 4: Configuring a Solaris Host to Use PAM

Installing and Configuring a Solaris Test System

Configuring the Client Machine

Specifying Rules for Authentication and Password Management

Authentication

Password Management

Step 5: Verifying that PAM is Interoperating with the LDAP Store

Step 6: Demonstrating that User Changes are Flowing to the Reciprocal Environment

Case 1

Case 2

Case 3

Case 4

Configuring Systems to Prevent Eavesdropping

Introducing Windows NT into the configuration

Example /etc/pam.conf File

B.  Identity Manager and Identity Synchronization for Windows Cohabitation

C.  Logging and Debugging

Glossary

Index

Introducing Windows NT into the configuration

Previously in this appendix, it was stated that the term Windows referred to Windows platforms using Active Directory for authentication. However, the system being discussed in this appendix can use Windows NT in place of (or along with) newer variations of Windows.

Be aware however, Windows NT lacks the ability to use on-demand synchronization normally provided by Identity Synchronization for Windows.

The Identity Synchronization for Windows’ on-demand synchronization process must be able to bind to Windows over LDAP, with a set of candidate credentials — an ability that the Windows NT authentication system lacks. When Identity Synchronization for Windows environments are configured with Windows NT they expect password changes to be captured at their source and at the time the change is made. This capture requirement has ramifications when you initially bring up an Identity Synchronization for Windows environment. Specifically, the Identity Synchronization for Windows system needs to see a password change for any entry before the entry is actually synchronized.

Synchronization in an NT environment is similar to the proceeding steps described in Case 3, where you can modify the passwords of all entries in the LDAP store using an LDAP-based utility. As these modifications go through the LDAP store system, Identity Synchronization for Windows forwards the captured passwords to the Windows NT system, and then neither of the two systems would contain stale passwords. However, because you created the passwords by deterministic means, it may be easy to guess these passwords.

With this technique, you can limit potential damage if you use Windows NT’s password policy administration to force all users to change their password at their next logon. As each user changes their password, the Identity Synchronization for Windows password DLL installed on the Primary Domain Controller will forward the password change to the LDAP store.