 |
| |
|
About authentication with FCDS
When users try to log into FirstClass, they are authenticated by either the FirstClass server or the external LDAP server (remote authentication). Which server does the authentication depends on the server you chose for authentication when you configured your FirstClass server.
You may be able to use the external LDAP server to authenticate users owned by that server. This depends on the type of LDAP server, and how it encrypts passwords.
If you choose remote authentication, this will be the authentication method for all users owned by the external LDAP server. Users owned by the FirstClass server will be authenticated by the FirstClass server.
For external connections to FCDS, you can set FCDS to allow anonymous logins, secure connections (SSL), or both.
 NotesUsers can disallow remote authentication for a particular connection by selecting "FirstClass secure authentication only" on the Service Setup form.
Subadministrators aren't authenticated remotely, even if remote authentication is being used.
LDAP BIND authentication
If you want to use LDAP BIND to authenticate remotely, you can specify an LDAP search filter. Only users who meet the filter requirements will be authenticated.
If the root DN on the external LDAP server is different from the FirstClass Directory root DN, you can also supply the root DN used on the external LDAP server. FCDS will use that root DN to construct users' DNs for authentication on the external LDAP server.
User replication mode
You can only use LDAP BIND authentication in user replication mode if the Directory root DN or authentication root DN matches the DN on the external LDAP server where all users have their credentials stored.
Authentication only mode
If you use one of the LDAP BIND authentication methods with authentication only mode, the LDAP BIND DN is formed by appending a Directory root DN (LDAP BIND) or the authentication root DN (LDAP BIND to Authentication Root DN) to the user ID.
Using FirstClass login tickets
LDAP clients can request FirstClass login tickets by issuing this BIND command in ASN.1 notation:
SEQUENCE
{ messid INTEGER,
APPLICATION [0]
SEQUENCE
{ version INTEGER (1 .. 127), - LDAP version [must be 3]
name LDAPDN, - user DN
sasl [3] SEQUENCE - authentication method: must be 3 [SASL]
{ sasl mechanism LDAPString, - authentication mechanism: "FC-SIMPLE"
sasl credentials OCTET STRING - contains user DN password
}
}
}
The FCDS reply containing the ticket is described in ASN.1 as:
SEQUENCE
{ messid INTEGER,
APPLICATION [0]
{ retCode ENUM, - return code [0-success]
matchedDN OCTET STRING - empty
errorMsg OCTET STRING - empty
sasl ticket [7] OCTET STRING - FC ticket [null terminated string]
}
}
To log into FirstClass using this ticket, the LDAP client must issue this BIND command in ASN.1 notation:
SEQUENCE
{ messid INTEGER,
APPLICATION [0]
SEQUENCE
{ version INTEGER (1 .. 127), - LDAP version [must be 3]
name LDAPDN, - user DN [not required]
sasl [3] SEQUENCE - authentication method: must be 3 [SASL]
{ sasl mechanism LDAPString, - authentication mechanism: "FC-TICKET"
sasl credentials OCTET STRING - contains FC ticket
}
}
}
Passwords and authentication
The FirstClass client supports cleartext passwords or passwords encrypted using MD5 or SHA hash algorithms.
For remote authentications, FCDS always passes cleartext passwords to the external LDAP server. At each login, users must enter their passwords, so that FCDS can pass this information in cleartext form to the external LDAP server. Users can't save passwords in their settings files, because the FirstClass client stores them in a hashed form that can't be converted to the cleartext form needed by FCDS. Users can save their user IDs, and this information, along with the typed passwords, will be sent in cleartext form.
Because FCDS needs cleartext user IDs and passwords as authentication credentials, you must deactivate MD5 hash logins when authenticating remotely.
Local versus remote authentication
When FCDS first creates the LDAP tree, it doesn't know whether users are synced from the external LDAP server or are native FirstClass users. All users at this point are considered local (belonging to the FirstClass server). After you do a full dir-sync with the external LDAP server, the synced users are identified as remote.
Authentication works differently for local and remote users. All local users are authenticated by the FirstClass server. For remote users, this is what happens:
Active Directory considerations
Microsoft Active Directory (Active Directory) must do all password maintenance, encryption, storage, and authentication for users administered on it, because Active Directory doesn't replicate passwords to the FirstClass Directory.
NoteSubadministrator accounts can't be authenticated by Active Directory.
Authenticating using user ID and password only
You can enable authentication by Active Directory where only user ID and password are required. The FCDS component which supports this isn't LDAP based, and therefore:
• the FirstClass Directory need not be replicated/synchronized with Active Directory
NoteIf you don't perform a full directory synchronization, FCDS won't know whether a user is local to the FirstClass server or is owned by Active Directory. If remote authentication fails in this case, the FirstClass server will look for local credentials.
• the root DNs on the FirstClass server and Active Directory needn't be the same.
The one requirement is that the user IDs and passwords on the FirstClass server match credentials on Active Directory.
To enable this type of remote authentication, choose Microsoft Active Directory Login at "Athentication mechanism" on the Authentication tab of the Directory Setup form.
iPlanet DS considerations
The Sun Microsystems iPlanet Directory Server (iPlanet DS) can store passwords in either cleartext or encrypted form. Whichever form is used is the form in which passwords are replicated to the FirstClass Directory.
| ||||||||||||||||||||||||