CityCat4

Сам squid по-моему это не умеет, обычно делают через logrotate или велосипедят, вот как я например :)

Есть внешние аутентификаторы, которые отвечают на запрос - разрешить ли данному юзеру запрошенный урл. Я полагаю, Вам придется его написать самому, ну или может быть, уже есть готовый.

В пути, который я давал - лежат все сообщения об ошибках, просто находишь нужную.

Исправить файл /usr/share/squid/errors/en/SQUID_ACCESS_DENIED

Подскажите - может есть что-то еще ?

Мне не известны. Возможно и есть, но решение AD + squid - оно уже настолько разобрано по полочкам, как его настроить во всех мыслимых и немыслимых комбинациях.
Но сразу:
Сейчас большинство трафика https, поэтому сразу понадобится бампинг, что автоматом тащит за собой свой CA и распихивание ключа этого CA по всем рабочим станциям политикой домена.

Есть ли какие то рекомендуемый на 2019 год анализаторы логов, веб панели ?

Вот как ни странно, никто не озабоитлся написать более-менее стоящий, более-менее красивый и более-менее удобный анализатор логов для squid. Поэтому тут каждый извращается настолько, насколько подскажет его фантазия и некромансерские умения :) - потому что запускать sarg, sams и прочее образца года лохматого - это нужно быть прокачанным некромантом :D А другого просто нет.

либо брать NetFlow.

netflow дает только статистику о соединениях - кто куда ходил. В качестве дополнительной аналитики можно, но не основной. Под что годится? Ну, например, выловить тех, кто всевозможные лайфхаки использует для обхода ограничений корпоративного прокси :)

или он может стоять как контроллер домена, воткнутый одним портом в коммутатор

Может. И обычно он так и стоит. Потому что обычно на этой же тачке крутится сервис анализа логов и веб-сервер для внутренней статистики...

У меня EL6, доводить до EL7 придется Вам самим.
- Как называется файл keytab? Если иначе чем krb5.keytab - его имя нужно передавать через окружение. Squid принимает его через переменную KRB5_KEYTAB, которую я занес в /etc/sysconfig/squid:

# Kerberos keytab file
KRB5_KTNAME="/etc/proxy.keytab"
export KRB5_KTNAME

- Принципал записан правильно? Вот так у меня выглядит auth_param:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/proxy.keytab -s HTTP/proxy.domain.tld@DOMAIN.TLD

Вот так выглядит external_acl, который отслеживает вхождение в группу:

external_acl_type full ttl=300 negative_ttl=60 children-startup=5 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -a -g AccessFull -D DOMAIN.TLD

(AccessFull - группа в AD)
- что говорит подобная команда?

kinit -k -t /etc/proxy.keytab HTTP/proxy.domain.tld

(должна отработать без вопросов)
Каким орбразом мапился принципал? Я для этого использовал команду виндовой консоли (делалось давно!):

ktpass -princ HTTP/proxy.domain.tld@DOMAIN.TLD -mapuser proxy -crypto rc4-hmac-nt -ptype KRB5_NT_SRV_HST -pass 123456 -out c:\proxy.keytab

(использовался доменный юзер proxy и его пароль)

Это не куча непонято чего, а параметры сборки. в squid может быть или не быть того или сего, поэтому параметры сборки - вещь достаточно важная. А верию он должен показать выше всего этого, например:

Squid Cache: Version 3.5.27
Service Name: squid

This binary uses OpenSSL 1.0.1e-fips 11 Feb 2013. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-l

Средствами squid такое не исключить, потому что здесь squid ни при чем. В сертификате отсутствует CDP, а в клиенте задана проверка списков отзыва. Соответственно ишак (а это предупреждает ишак) говорит, что "не шмогла".
Если это сторонний сертификат - то лучше отключить проверку списков отзыва. Если это сертификат, который используется для бампинга ("поддержка https" - имелся в виду бампинг, позволяющий контролировать https-трафик?) - то нужно добавить в него CDP, пусть даже там будет лежать фиктивный пустой CRL.