|
|
|
|
Add a <Credentials> element for verifier types that require a username and password combination for access. Only one such element is allowed. The following verifier types support the <Credentials> element (both as top-level or as sub-verifiers in a <Multi> element): <LDAP>, <Communigate>, and <DataBase>.
Credentials cannot be shared across sub-verifiers by putting credentials at the top of a <Multi> verifier. A <Credentials> element must contain both a <Username> and one of the supported types of password element. The <Password> element can be encrypted or clear text.
sub-element: <Username>
The <Username> element can contain any text. For an LDAP verifier, it is the Distinguished Name (DN) to bind with. For a DataBase or Communigate verifier, it is simply the user name.
sub-element: <Password>
The <Password> element contains the password in clear text.
sub-element: <EncPass>
The <EncPass> element contains the encrypted password.
When you submit a verifier through the Red Condor Provisioning API, you can enter the clear text of the password into a <Password> element. It will then be transformed into an encrypted version and stored internally within an <EncPass> element. If you know the <EncPass> text corresponding to the password, you can craft your Red Condor Provisioning API submission with an <EncPass> element instead of a <Password> element.
If you do not supply credentials to an LDAP server, an anonymous bind is attempted. Because SQL servers can be configured to trust certain hosts without a password, you can also omit credentials from a DataBase verifier. Currently, connections to the Communigate server require a <Credentials> element. This requirement may change in a future release.