Samba4: Optional PACs for Unix clients
I've been asking consultant-friends about field deployments of AD, & how corporations use it. Their answers turn out to explain why AD admins & Unix-krb admins differ on whether PACs work.
Summary: PACs don't work well in "one big realm" krb-deployments, which are the norm for Unix. (end summary)
Unix-krb sites traditionally set up one big krb-realm, and they minimize use of inter-realm krb (in part because inter-realm referrals aren't yet well-specified, and unlike MS, Unix krb-admins care about standards-compliance.). One big realm implies one big set of group-names, so some users end up with oversized PACs. That leads to breakage, so some Unix-krb admins dislike PACs.
On the Windows side, there are two patterns of AD deployment: Small-to-midsize companies tend to have many small AD domains (one per LAN, or one per dept, something like that). The group name-space has two segments:
- a global set of group-names, which gets synchronized across all of the domain-servers; and
- each small domain has some local group names that mean nothing to other groups, and which other groups don't know about.
In this "many-small-domains" setup, each small domain has a small-enough set of group-names, so PACs don't get too big, even for users who are members of all the groups that their domain knows about. Running many small domains works for AD customers, because AD's inter-realm stuff is pretty easy to manage (albeit non-standard, & insecure in spots).
The second style of AD deployment is the Fortune-500 way: One big company-wide domain, with many cloned satellite servers to meet scaling needs. In these deployments, the list of group names is large & universally visible, and PACs do get very big. So big, in fact, that accessing a Windows app-server can take one full minute of latency, while the app-server chews over the ticket's big PAC and the server's big set of ACL-rules. In these sites, people just accept that using networked services tends to run slow, and that sometimes AD has weird failures. Unix sites have seen before that PACs work poorly in this "one big realm" style of deployment. Since "one big realm" is the norm in kerberized Unix sites, the Unix-krb community isn't interested in having the MIT-krb distro _rely_ on PACs for authz.
