Before opendirectoryd: NetInfo, DirectoryService & the Open Directory era

3How network users worked, end to end

Era A NeXT / NetInfo

An admin created a user in a shared NetInfo domain (root /) rather than the machine-local one. A workstation resolving a non-local user searched its login hierarchy — "starting with the local domain and proceeding toward the root domain until the needed data is located" — and compared the typed password to the record's crypt(3) hash. There was no password server: the hash was the directory field. Home directories lived on NFS and appeared at /Net/hostname/share via the automounter, driven by /mounts records with a net option. lookupd cached everything, invalidating against the NetInfo database checksum.

Era B Mac OS X Server Open Directory

Promoting a server to Open Directory Master (slapconfig -promotereplica) stood up a coordinated trio:

A client was bound via Directory Utility (the LDAPv3 plugin + a spot on the authentication search path; 10.4+ added mutually-authenticated trusted binding). At login, loginwindow asked DirectoryService to find the record, then read its AuthenticationAuthority attribute to decide how to verify — preferring Kerberos (AS-REQ → TGT, enabling SSO to AFP/mail/SMB/VPN), falling back to Password Server SASL for non-Kerberized services. On success it mounted the network home from the record's HomeDirectory URL blob and applied MCX managed preferences.

Extras that defined the era: Portable Home Directories / mobile accounts (;LocalCachedUser;, HomeSync engine — laptops working offline); MCX preferences attached to user/group/computer records; and up to 32 replicas per master (a 10.6 master handled ~200,000 records / 8,192 client connections). The admin GUI was Workgroup Manager.

4Usage: create, list, remove a user

The actual commands, by era — and how a shared/network domain changed them

Era A NeXTSTEP / NetInfo (niutil, niload/nidump)

The domain argument selected the target: . = local machine, / = root of the bound hierarchy (the network/shared domain), and -t host/tag = a specific database not yet wired into a hierarchy.

# Bulk: load a UNIX passwd file straight into a domain
niload passwd . < /etc/passwd          # load flat file into LOCAL domain
nidump passwd .                         # "list": dump domain back out as passwd(5)
nidump passwd . | grep bob              # find a user

# Direct record CRUD with niutil
niutil -create   . /users/bob
niutil -createprop . /users/bob uid 701
niutil -createprop . /users/bob gid 20
niutil -createprop . /users/bob home /Users/bob
niutil -createprop . /users/bob shell /bin/tcsh
niutil -createprop . /users/bob passwd '*'
niutil -read    . /users/bob            # read the record back
niutil -destroy . /users/bob            # remove the user

Local vs. shared domain — what changed: just the domain argument. Apple's own NetInfo guide creates the parent domain by tag because it "is not yet connected to a hierarchy":

nidomain -m myschool
niutil -createprop -t server1/myschool /machines/server1 serves ./myschool
niutil -create -t server1/myschool /users
niutil -create -t server1/myschool /groups

The GUI path was UserManager.app (/NextAdmin): authenticate as root, then in the domain browser "Click '/' (the root domain)… then click OK" to place the account in the shared domain. The 3.3 manual literally warns "it's easy to click OK prematurely."

Era A→B Mac OS X 10.0–10.4 (nicl, and dscl arrives in 10.3)

NetInfo stayed the local store behind DirectoryService. nicl edited it directly; note that modify = delete + recreate:

nicl / -create /users/bob uid 701
nicl / -create /users/bob shell /bin/tcsh
nicl / -create /users/bob home /Users/bob
nicl / -create /users/bob realname "Bob Jones"
passwd bob                              # set the real crypt hash
nicl / -delete /users/bob shell        # "modify" a property
nicl / -delete /users/bob              # delete the user

Era B Open Directory (dscl, dseditgroup, pwpolicy, dsimport)

The node argument now selects the directory: . or /Local/Default for local, /LDAPv3/127.0.0.1 for the server's own network domain.

# Local node CRUD
dscl . -create /Users/bob
dscl . -create /Users/bob UserShell /bin/bash
dscl . -create /Users/bob RealName "Bob Jones"
dscl . -create /Users/bob UniqueID 1001
dscl . -create /Users/bob PrimaryGroupID 20
dscl . -create /Users/bob NFSHomeDirectory /Users/bob
dscl . -passwd  /Users/bob "s3cret"
dscl . -list   /Users                  # list all users
dscl . -read   /Users/bob              # read one record
dscl . -delete /Users/bob              # remove
dscl . -authonly bob s3cret            # test authentication

# Operate on the NETWORK directory — just swap the node
dscl /LDAPv3/127.0.0.1 -list /Users
dseditgroup -o edit -n /LDAPv3/127.0.0.1 -u diradmin -a bob -t user staff

# Password policy, and bulk import (Workgroup Manager shells out to this)
pwpolicy -a diradmin -u bob -setpolicy "minChars=8 maxFailedLoginAttempts=3"
dsimport users.txt /LDAPv3/127.0.0.1 M --username diradmin dirpass

Interactive navigation felt like a filesystem — dscl localhost then cd /LDAPv3/dir.example.com/Users, ls. Password Server was built with mkpassdb; the KDC with kdcsetup / kadmin.local -q "add_principal bob". GUI: Workgroup Manager (accounts) + Server Admin / Directory Utility (services & binding).

5Local user vs. network user, side by side

The discriminator is the AuthenticationAuthority attribute and where the hash actually lives

A local and a network user look almost identical except for three things: the AuthenticationAuthority value, the shape of the home-directory attribute, and — critically — where the password actually lives. A network user's record contains no hash at all.

AuthenticationAuthority: ;ShadowHash;
GeneratedUID: 6B6A...C2
NFSHomeDirectory: /Users/bob
UniqueID: 1001
PrimaryGroupID: 20
UserShell: /bin/bash
# password hash → /var/db/shadow/hash/6B6A...C2

AuthenticationAuthority:
  ;ApplePasswordServer;0x<slot>,<pubkey> 10.0.1.1:106
  ;Kerberosv5;;bob@REALM;REALM;
HomeDirectory:
  <home_dir><url>afp://files.example.com/Users
  </url><path>bob</path></home_dir>
NFSHomeDirectory: /Network/Servers/files…/bob
# hash → Password Server + KDC, NOT the record

6Protocols altogether: NFS, LDAP, Kerberos, SMB — which did what

Your direct question — was NFS, Kerberos, SMB, LDAP involved? — has a per-era answer. Here it is stated plainly, then walked through as two concrete logins.

End-to-end: a NeXT network login

loginwindow → lookupd → NetInfo RPC to the bound parent/root netinfod fetches /users/bob → crypt(3) compare against the record's passwd → home mounted by the NFS automounter from /mounts. Kerberos, LDAP and SMB are not involved.

End-to-end: a bound 10.4/10.5 network login

1. loginwindow → DirectoryService searches the authentication search path.
2. The LDAPv3 plugin finds /Users/bob over LDAP (389).
3. DirectoryService reads AuthenticationAuthority and dispatches:
   • ;Kerberosv5; → Kerberos AS-REQ to the KDC (88) for a TGT — this is what powers SSO to AFP / mail / SMB / VPN.
   • ;ApplePasswordServer; → SASL to Password Server (106 / 3659) for services that can't use Kerberos.
4. On success, the automounter mounts the home over AFP (548) or NFS (2049) from the HomeDirectory/mounts records; MCX applies.
5. SMB (445/139) enters when a Windows client authenticates the same OD account — Samba validates against Password Server's SMB-NT/SMB-LM hashes. The Active Directory plugin case swaps the trio for AD's own LDAP + AD Kerberos + DNS SRV + SMB machine-join.

One more protocol worth naming: DSProxy — DirectoryService's own protocol over TCP 625 — let Workgroup Manager on an admin box drive a remote DirectoryService daemon. Leopard (10.5) also added the Local KDC (LKDC): every Mac got a per-host realm LKDC:SHA1.<hash> for peer-to-peer Kerberos (AFP, Screen Sharing, Back to My Mac) without a server.

7Network applications & the /Network domain

Yes, the concept existed — and on NeXT it genuinely worked

NeXT had a real network-applications tier. The four-domain model predates the /Network directory: NeXTSTEP used prefixes — ~/Apps (user), /LocalApps + /LocalLibrary (site/network), /NextApps + /NextLibrary (vendor), with a /Net folder for remote filesystems. Workspace Manager's search order (~/Apps → /LocalApps → /NextApps → …) is exactly the user→local→network→system precedence Mac OS X later formalized.

And it was productized: SimpleNetworkStarter made a shared /LocalApps a checkbox — the server exported it, and it "shows up on each computer as /LocalApps," a NetInfo-driven NFS automount with no per-client setup. One copy of Mathematica ran from the server across the whole lab, and fat (multi-architecture) binaries let a single NFS-served .app launch on m68k, i486, SPARC and PA-RISC machines alike.

Mac OS X formalized it — then quietly stranded it

Rhapsody/Mac OS X replaced the prefixes with explicit domain roots, and the Network domain got standard directories: /Network/Applications, /Network/Library, /Network/Servers, /Network/Users, reachable via NSSearchPathForDirectoriesInDomains() with NSNetworkDomainMask (since 10.0). Server-side, Workgroup Manager's Network Mount tab had a literal radio button — "Shared Applications folder" → automount at /Network/Applications (a -static autofs map), alongside "Shared Library folder" and user homes.

The network-application idea that did ship at scale: NetBoot

The real productized "apps from the network" was booting the whole system over the network. NetBoot — demoed by Jobs at Macworld Jan 1999 with a diskless iMac — used BOOTP/DHCP + TFTP + disk images over AFP (later NFS, then HTTP in 10.4). NetBoot 2.0 (10.2+) added Apple's Boot Server Discovery Protocol (BSDP). Diskless clients booted from a read-only image with per-client shadow files absorbing writes, so every restart restored pristine state; NetInstall reused the mechanism to image local disks. It persisted into the macOS Server 5.x era and died with T2/Apple-silicon Macs.

The Mac-era analog of "network apps" was less "serve the binary" and more "control which binaries launch" — MCX Application Launch Restrictions, enforced in 10.5 by the mcxalr agent by code signature. That, too, gave way to configuration profiles / MDM in 10.7.

8The DirectoryService daemon architecture

What "Open Directory" actually named before opendirectoryd — and why it matters for a port

Before Lion, "Open Directory" was a client architecture shipped since 10.0: the DirectoryService.framework access API, the /usr/sbin/DirectoryService daemon, and a C plugin API. Everything was abstracted as nodes — /NetInfo/root, /LDAPv3/…, /Active Directory/…, /Local/Default — with a special /Search node implementing the authentication search policy (LSPSearchPath/NSPSearchPath/CSPSearchPath).

The public API (DirServices.h) used opaque handles — tDirReference, tDirNodeReference, tRecordReference — and marshalled all data through tDataBuffer structs, with dsOpenDirService, record CRUD, dsDoDirNodeAuth, and a dsDoPlugInCustomCall passthrough. A notable variant, dsOpenDirServiceProxy, connected to a remote daemon over TCP 625. Record/attribute types carried either a portable dsAttrTypeStandard: prefix or a backend-native dsAttrTypeNative: prefix, with the LDAPv3 plugin's mapping tables translating between them.

Plugins were bundles loaded from the framework's Resources/Plugins (Apple) and /Library/DirectoryServices/PlugIns (third-party), built -bundle_loader /usr/sbin/DirectoryService. The roster evolved: NetInfo → LDAPv3 + native Active Directory + BSD flat-files + the Local plugin (which replaced NetInfo in 10.5, storing dslocal plists). Through 10.4, libc calls went through a separate lookupd; in 10.5 DirectoryService absorbed libinfo resolution and memberd, with dscacheutil/dsmemberutil as the new CLIs.

9Why Apple moved to opendirectoryd

The transition came in two steps. 10.6 Snow Leopard introduced OpenDirectory.framework (the ODSession/ODNode/ODQuery/ODRecord class cluster) as a modern client API — but it still talked to the same old DirectoryService daemon underneath, and deprecated the legacy C framework. 10.7 Lion then removed the daemon itself and replaced it with opendirectoryd.

Motivations analysts cited, in rough priority: fault isolation (XPC modules can't take down the daemon — the single biggest driver given DirectoryService's crash history); security/sandboxing via per-module address spaces; the move to 64-bit + launchd + libdispatch; and code sharing with iOS, which used the OpenDirectory stack without the legacy plugin baggage. Legacy third-party .dsplug plugins survived only through a compatibility shim, dspluginhelperd, before full removal.

Early Lion opendirectoryd was notoriously unstable in AD environments — "network accounts are unavailable," failed binds, 100% CPU — until 10.7.2. The server side then decayed steadily: MCX/Workgroup Manager → Profile Manager; the Jan 2018 gutting of macOS Server down to just Open Directory + Profile Manager; the macOS Server app discontinued April 21, 2022. The client-side opendirectoryd is still the live directory daemon on macOS today.

10Local vs network users — every version

Exact records, storage paths, password location, and home-mount protocol per era (verified 2026-07-16)

§5 gave the concept; this is the exhaustive version. The record shape, the on-disk path, where the password lives, and how the home is mounted all shifted at specific version boundaries — three of them non-obvious (the 10.3 hash externalization, the 10.5 NetInfo→dslocal move, and the 10.7 hash re-embedding). Each era below shows a local account beside a network account.

Era 1 NeXTSTEP 3.x — NetInfo, crypt in-record

# niutil -read . /users/bob
name: bob
passwd: a89d3Kk1mNP0Q   # DES crypt — IN-RECORD
uid: 501
gid: 20
realname: Bob Example
home: /Users/bob
shell: /bin/csh

# same property layout, physically in the
# PARENT domain DB (often on another host,
# reached via local→network→root binding)
name: bob
passwd: a89d3Kk1mNP0Q   # crypt, in the shared record
uid: 501
home: /Net/server/Users/bob
shell: /bin/csh

Password: DES crypt(3) in the record's passwd property — no external file, no separate authority. Home mount: NFS only — a NetInfo /mounts record (name: server:/Users, dir: /Net/server/Users, vfstype: nfs, opts: net) hands the mount to the automounter, landing at /Net/<host>/<share>. NFS 2049 + portmap 111. No AFP client existed for NeXT homes.

Era 2 Mac OS X 10.0–10.4 — NetInfo, the hash walks out

# 10.2 and earlier: crypt in-record
authentication_authority: ;basic;
passwd: 3dI880QaIz.Wk   # DES crypt

# 10.3 Panther: hash moves OUT →
authentication_authority: ;ShadowHash;
generateduid: 70902C33-AC79-11DA-…
passwd: ********        # placeholder
# real hash: /var/db/shadow/hash/<GUID>

# home now an XML blob with a URL scheme
home:
 <home_dir><url>afp://server/Users</url>
 <path>bob</path></home_dir>
uid: 1025
# password validated by Password Server,
# not a local hash file

Password boundary: 10.3 Panther externalized the local hash from the record to /var/db/shadow/hash/<GeneratedUID> (a multi-hash blob; 10.4 added salted-SHA1) and switched the authority from ;basic; to ;ShadowHash;. Home mount: AFP default, NFS optional — the afp:///nfs:// <home_dir> blob, mounted by the classic automount(8) daemon (maps -fstab/-static/-nsl) at /Network/Servers/<server>/<share>/<path>. AFP 548, NFS 2049.

Era 3 Mac OS X 10.5–10.6 — dslocal plists + LDAP, autofs

<key>name</key>        <array><string>bob</string></array>
<key>realname</key>    <array><string>Bob Example</string></array>
<key>uid</key>         <array><string>501</string></array>
<key>home</key>        <array><string>/Users/bob</string></array>
<key>generateduid</key><array><string>70902C33-…</string></array>
<key>authentication_authority</key>
  <array><string>;ShadowHash;</string></array>
# NO ShadowHashData key yet —
# hash STILL external: /var/db/shadow/hash/<GUID>

objectClass: inetOrgPerson posixAccount
             apple-user extensibleObject
uidNumber: 1025
homeDirectory: /Network/Servers/…/bob
apple-generateduid: 8E39B2E0-…
apple-user-homeurl: <home_dir><url>
  afp://server/Homes</url><path>bob</path></home_dir>
authAuthority: ;ApplePasswordServer;0x<slot>,…
authAuthority: ;Kerberosv5;;bob@REALM;REALM;
# LDAP DB on disk: /var/db/openldap/openldap-data/
# hash NOT here → authserver + KDC

Path move: 10.5 Leopard retired NetInfo — local accounts became per-user XML plists under /var/db/dslocal/nodes/Default/users/ (keyed by short name, e.g. bob.plist; siblings groups/ computers/ config/ aliases/). The local hash was still external (/var/db/shadow/hash/<GUID>, salted-SHA1). Network hashes live off-LDAP in Password Server (/var/db/authserver/authservermain) + KDC (/var/db/krb5kdc/principal). Home mount: autofs — automountd (launchd on-demand) triggers under /Network/Servers; the actual mount is performed by NetAuthSysAgent at Login Window using the user's own credentials (homes are unmounted then remounted per-user). Protocol from the URL scheme: AFP 548 default, SMB 445, NFS 2049. autofs doesn't use the user's Kerberos ticket — creds go in the mount map.

Era 4 Mac OS X 10.7+ — opendirectoryd, hash re-embedded

<key>ShadowHashData</key>   # NEW in 10.7 — embedded
<array><data>bplist00…</data></array>

# 10.7 Lion:  SALTED-SHA512
# 10.8+:      SALTED-SHA512-PBKDF2 {
#   entropy = <128-byte derived key>
#   salt    = <32-byte>
#   iterations = ~45000 }
# /var/db/shadow/hash/ no longer used

# record shape identical to Era 3;
# hashes still in authserver + KDC.
# What moved is the CLIENT config:
/Library/Preferences/OpenDirectory/
  Configurations/LDAPv3/<server>.plist

apple-user-homeurl scheme migrates:
  afp://…  →  smb://…   # SMB2 default in 10.9

Password boundary: 10.7 Lion pulled the local hash back into the plist as the binary ShadowHashData key (SALTED-SHA512), and 10.8 switched it to SALTED-SHA512-PBKDF2 (entropy/salt/iterations). The external /var/db/shadow/hash/ file is gone. Home mount: transport stack unchanged (autofs + NetAuthSysAgent), but 10.9 Mavericks made SMB2 the default Apple file-sharing protocol, AFP demoted to fallback (later removed entirely ~macOS 15). Mobile/Portable Home accounts are the exception throughout 10.5+: not mounted at all — synced by FileSyncAgent/HomeSync against a local /Users/<name> copy.

Path & storage summary

Home-mount protocol summary

11Implementation language by component

Verified from actual source-file extensions in the pinned repos/tags — the C → C++ → Objective-C arc

The language tracks the generation almost perfectly: NetInfo is C, DirectoryService is C++ (behind a C API), OpenDirectory is Objective-C. The password/policy tier is a genuine polyglot. Verified by counting .c/.cpp/.m/.mm in each tree.

12What this means for NextBSD

Verified source-availability audit of apple-oss-distributions + the aosm mirror (2026-07-16)

Compiled for the NextBSD OpenDirectory scoping, the reusable-code question was audited directly against the GitHub mirrors rather than taken on trust. The headline correction: the code to port is the 621.12 (10.6.8) generation, not the 655 tag I first cited — by Lion the plugins had already been gutted out of the tree. And "port DirectoryService" is really four separate repos plus one hole.

13Sources

~100 primary and contemporary sources across 7 research agents. Selected, deduplicated below; man pages cited by version, Apple source by project/tag.