There are many commercial flavours of UNIX but you may have noticed that none of them are actually called "UNIX". This is because the name is the property of "UNIX System Laboratories". Despite the various names and branding, all commercial UNIX variants are derived from code originally developed in the early 1960's at Bell Laboratories, and then by several American Universities, mainly:

1. UCB (University of California Berkeley) - Known as BSD (Berkeley Standard Distribution).
2. UMIT (University Massachusetts Institute of Technology) - Eventually became known as SVRn (System Five Release 1/2/3/4).

NB: There are also some lesser common variants such as SCO (Santa Cruz Operation) and Microsoft's Xenix.

Whilst the bulk of the code used in the internals of the various distributions is largely the same, there are a few areas where security needs to be treated quite differently. The largest single area is group management. Kernels based on UCB code (e.g. IBM's AIX) make great use of "groups", which allows for greater control of who can access what. SVRx (e.g. Solaris) on the other hand has most of the Operating System utilities owned by a single group (bin), and decisions on access are made at runtime. E.g. In BSD UNIX you can create a "wheel" group, and only members of this group can become the superuser (root). SVRn on the other hand, allows anyone who knows the "root" password to become the superuser.

UNIX recognises a user, and their level of access/privilege, by their user and group identification number(s) stored in "/etc/passwd" and "/etc/group". When a user account is created, a unique id-number is assigned (usually the next available number). If you have multiple systems, it is possible to have different users with the same user-id, or the same user with different id's on each system. UNIX only identifies file ownership, and access levels, by using these numeric-id's, therefore, you can change a username whilst leaving the ID the same, with no effect, other than the new name is now shown as being the file's owner.

The problem becomes worse when files are shared with/transferred to another system. Files that belong to user "fred" on "system_a", are thought, by "system_b", to belong to "belinda", because coincidentally, they were allocated the same user-id. This is even more awkward when using NFS. The other system will only see the user-id, therefore you may get the wrong level of file access, or even none at all! If you access NFS files from a PC, and don't run PCNFSD (PC Network Filesharing Daemon) all users are seen as "anonymous".

This problem can be overcome by coordinating the creation of user-accounts, and ensuring that id's are unique, and consistent across all systems in the enterprise. There are various tools (including HP's Service Controller Manager and BMC's Control-SA), that can centralise the creation and maintenance of accounts and groups. (SCM also introduces the concept of "roles" to HP-UX).

These kinds of tools come in two major types:

1. Password Synchronisation products
2. Centralised user management products

The password synchronisation products (e.g. NIS or DCE) rely on a central server that holds all the user information and passwords. All authentication has to be done by first connecting to a central server(s). The problems associated with this approach are:

1. If the server is down, nobody can login
2. Compromising the central server can give you access to the entire enterprise