Don: New page: 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...

2009-08-31T17:39:06Z

New page: 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...

New page

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.
----

Samba4: Optional PACs for Unix clients - Revision history

Don: New page: 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...