Summary

  • RFC 2307 proposed LDAP entries for Unix users, groups and network resources. Its posixAccount schema included uidNumber, an integer consumed by operating-system lookup functions.
  • The RFC's security section named the consequence of careless write access: a user allowed to change uidNumber could make their account equivalent to the superuser. The schema carried authority because Unix software acted on the value.

A name lookup starts with a number

A process did not ask a directory to explain who someone was. It handed a C library function an integer and expected the account record attached to it. RFC 2307 uses getpwuid() as its example: the function maps a user ID to a login name. In the proposed LDAP form, that search looks for a posixAccount whose uidNumber matches the number supplied by the program.

The field looks like a filing detail. The program treats it as identity.

Before LDAP entered this picture, networked Unix sites could share account and host data through the Network Information Service. Sun's administration guide describes NIS maps as two-column key/value tables. A domain's master server held the maps; slave servers kept copies; clients queried either. The passwd.byname map searched by login name, while passwd.byuid used the user ID as its key. Administrators built maps from local input files on the master and propagated the results to slaves.

That arrangement turned a file edit into a network decision. Change a source file, rebuild a map, and the answer became available to clients across the domain. The clients did not vote on whether the new number was wise. Their lookup code consumed the value they received.

Sun's 1999 manual records a small corporate detour: NIS had formerly been called Sun Yellow Pages, and the functionality stayed the same after the name changed. The label moved; the account maps did not become less consequential.

LDAP offered a different directory, not a harmless one

LDAPv3's 1997 specification set out a lighter way for clients and servers to access directory information than the full X.500 Directory Access Protocol. Three months later, RFC 2307, titled An Approach for Using LDAP as a Network Information Service, proposed classes and attributes for Unix and TCP/IP records inside LDAP.

The list reached well beyond host names. It covered users and groups, services and protocol numbers, RPC identifiers, boot parameters, network addresses and NIS netgroups. A posixAccount entry could carry a login name, a display name, uidNumber, gidNumber, a home directory and a login shell. RFC 2307 even supplied a sample password-file-style record, translated into directory attributes.

The proposal made sense as an integration move. Unix programs already asked the C library for account data; a system could point that lookup at a network directory instead of a local file. RFC 2307's implementation section described an LDAP-backed NIS server, reference C-library code and scripts that converted files such as /etc/passwd and /etc/hosts into directory entries.

The document did not order every Unix site to migrate. It was published as Experimental, and its purpose was to offer an approach for organizational nameservice. It said the mechanism had already been implemented with some success; it did not count installations or measure adoption.

The number was the boundary

RFC 2307's security section is unusually direct about what a directory attribute could do. It says that only administrators should modify the schema's operating-system entries. Then it gives the reason: if a user could change their own uidNumber, they could subvert security by making their account equivalent to the superuser account.

RFC 2307 states a conditional risk and names the control point: Unix software matched the number to an account; a directory could publish that match to many clients; whoever controlled writes could alter the identity those clients saw. Unix software matched the number to an account; a directory could publish that match to many clients; whoever controlled writes could alter the identity those clients saw. The schema describes syntax. The access rule decides who may assign the consequence.

The same section spots a second collision between lookup and power. Making widely used encrypted password hashes available to non-privileged readers could expose them to dictionary and brute-force attacks. RFC 2307 framed that pattern as compatibility with existing Unix systems and recommended a strong authentication service where security mattered. A shared directory could simplify lookups while also putting sensitive account material within reach of a broader set of clients.

The evidence here establishes a design and its stated risks, not how widely the LDAP mapping spread. RFC 2307's implementation note is evidence of an implementation; no source in this packet measures deployment across Unix systems.

The important change was not a database acquiring a new schema. It was an operating system agreeing to let a network answer a local question. uidNumber could sit in a table, but the process that interpreted it supplied the force. Moving the record from /etc/passwd to NIS or LDAP moved the control point too: the administrator now had to know which source was authoritative, which replicas had the current map, and who could alter the identity field.

Sources