You can grant (and deny) access  to everything as a policy per
application.

That would be at

Central Administration <https://central.mindsharp.com/> > Application
Management <https://central.mindsharp.com/_admin/applications.aspx> >
Policy for Web Application

Well, that did not work well. This should be easier to read:

Central Administration > Application Management > Policy for Web
Application

A smart, consistent use of the sites  directory will accomplish this for
you.

Allow me to clarify. The company  directors don't just want to SEE what
sites are available, they want to be able to at least READ (and possibly
contribute to) any content on any site without having to go through the
"enter credentials three times, then request access  from the site
administrator" process. They want to be able to search across ALL sites
to find information. They'd like administrator access, but I don't want
to make them administrators for fear of unexpected results from
well-intentioned modifications.

create an AD group for them all,
then use a policy to give  them all read access  to all sites  at the web
application level.

But they will still have to authenticate or the site will not know who
they are to determine what they can do.

AD Authentication is set in our company  when you log in to your computer.
Once you have logged into the network MOSS 2007 knows who you are because
we've imported the AD list into MOSS.

Importing the AD list to create user profiles doesn't affect how MOSS
works with and depends on the underlying authentication processes in
IIS.

They could set their browsers to automatically login if this is an
issue.

Actually, unlike 2003, in 2007 making them administrators will not
automatically give  them access  to all sites. Policies seems to be the
way to go. We came to the same conclusion with service accounts for
our applications which need to access all sites.

With Integrated Windows Authentication, you do not need to import the AD
list into MOSS in order for MOSS2007 to know what access  to give  each
user. When a client connects to a site, the user's credentials are
presented to MOSS. These credentials include any AD group memberships
that the user may have. MOSS then checks each of these group memberships
to see what SharePoint groups  the user is a member of. Together with any
SharePoint group memberships that the user may have via the individual
user account, and any permissions granted to individual users, this
determines what privileges the user is granted on each SharePoint
resource.