### Password Aliases

If you're using a "single sign-on" system that allows you to share the same password across different machines/servers/applications, etc. you can setup Password Safe entries accordingly, so that changing one password affects all other related entries. This is called "aliasing" entries. This section describes how to define and use such aliases.

#### Summary

The basic idea is to allow one entry's password to be referred to by another. The "referred to" entry is called the base, and the "referring" entry (or entries) is (are) called the alias(es). When an entry is set to be the alias of another entry, the alias's password effectively "follows" that entry's password: If you copy the alias' password to the clipboard, the password that gets copied is the base's. If you change the base's password, this is immediately reflected in all the alias entries associated with the base. Although this may sound complicated, in fact it's quite simple and intuitive to use. The hardest part is setting up the aliases, as described below.

#### Defining an alias

In Password Safe, an entry can refer to another's password by means of a specially formatted password in the referring entry. The format is the "name" of the referred-to entry enclosed in square brackets. Most of the time, you can think of "name" as synonymous with the title field of an entry, so if the base entry's title is "master", for example, then entering "[master]" (without the quotes) in another entry's password field is enough to define the other entry as an alias of "master".

In the general case, a "name" can contain all of the following fields, separated by colons: Group, Title and User name. Note that if the title is unique in the database, then the other fields are optional. Likewise, if the group and title together or title and user together specify a unique entry, then the corresponding user or group doesn't have to be specified.

In Password Safe entries, only the Title field is mandatory. Group and User name fields are optional as long as the resulting combination of "group/title/user name" is unique. As indicated above, the alias' "password" is in the form [g:t:u] but in fact you only have to specify enough information to uniquely identify the base entry. So, if there is only one entry in the database with title 't', then [t] would be sufficient - since title is mandatory and only one item is given, it is assumed to be the title. If there were more than one entry with this title, you would be warned that this is the case, and you would need to be more specific to identify the base entry by adding either its group or its user name or both! As long as there is a unique entry that fits the information provided, any of the following formats are accepted: [g:t:u], [g:t], [t:u] or [t]. Specifying a colon without a value implies an empty field, e.g. [g:t:] says entry with title 't' in group 'g' and with no user name value and [:t:] says entry with title 't' in the root with no user name value etc.

The following examples should make this clear.

#### Examples

1. If the base entry's title is "LDAP Server", and there are no other entries with that title, then an alias will be defined by an entry that has "[LDAP Server]" in the password field.

2. If there are "LDAP Server" entries in two different groups, say "Dept. A" and "Dept. B", then one can specify an alias to the latter by "[Dept. A:LDAP Server]". Note you do not have to specify the user name if the information you have provided uniquely identifies the base entry.

3. Different user names can also be used to differentiate between similar base entries, e.g., "[LDAP Server:Joe]" and "[LDAP Server:Mary]".

4. Finally, all three fields may be specified, as in "[Dept. A:LDAP Server:Joe]"

#### Display

Base entries, that is, entries with at least one alias "pointing" to them, are displayed with a green triangle instead of a green square in the nested tree view.

Alias entries are shown with white triangles.