CityCat4

"Доменный" компьютер - это тот, который имеет учетку в домене. Учетка в домене нужна чтобы как минимум проходила аутентификация через керберос, без ввода пароля. Именно этот факт - без ввода пароля и есть признак - "доменный" или "чужой".
"Чужой" тоже может получить список пользователей и даже аутентифицировать юзеров, но для этого ему самому сначала надо в домене аутентифицироваться. Обычно это делается созданием фейкового юзера, не имеющего никаких прав и имеющего простой текстовый пароль. Пароль этого юзера указывается в конфиге в открытом виде. Так работает аутентификация через апач (AuthBasicProvider ldap), так работает PAM-модуль pam_ldap.so и NSS-модуль nss_ldap.so, так может работать аутентификатор squid. Так работает любой скрипт на Perl/PHP, которому нужно аутентифицировать юзеров в AD - redmine, horde, любой велосипед, использующий Net::LDAP.
Конечно, это неудобно и небезопасно. Поэтому и создают учетки компам в AD, настраивают керберос через ktpass и полученный keytab сбрасывают на линух - так например делают для squid.
Аутентифицироваться в домене можно и не заводя учетку. Но логин и пароль хоть какого-нибудь юзера из домена комп, который аутентифицируется, должен знать.

Ничего не получится. Да, AD - это LDAP. На нем работают все инструменты LDAP, ldapsearch например. Но это хитровывернутый LDAP, не совместимый ни с чем, кроме самого себя. Читать данные с OpenLDAP он, может быть еще как-то будет. Писать он туда не сможет, потому что ожидает там AD, а там не AD. Единственный способ сохранить данные - мигрировать их в AD. Или там у Вас какая-то сильно нестандартная схема?

Потому что самба такая самба. Это повелось еще с лохматых времен - иногда она ни с того ни с сего выпадает из домена. Можно проверить время на компе и в домене - оно не должно отличаться по-моему больше чем на 5 секунд.

Процесс добавления UNIX в домен описан был еще в лохматом 2005 году. Ссылка раз. Ссылка два. Статьи эти публиковались в журнале "Системный администратор" в соответствующее время. Процесс добавления конкретно центоса в домен без самбы (на самом деле самба там совершенно не-пришей-кобыле-хвост) был описан в статье "За пределами nss_ldap или еще ор методах авторизации", которую "Системный администратор" публиковал по-моему в марте 2015-го. Ссылку дать не могу - сайт, с которого предыдущие ссылки, автором заброшен, там последнее обновление в 2011 году :D

Но добавление центоса в домен не даст автоматически прав доменным админам прав администратора. Все, что оно сделает - это сделает на центосе известными учетки домена.

Проксевых решений не так уж и много, и это как правило squid. Анализаторов логов тоже не больно много, и не все их них живые - sarg, sams...

Я Вас огорчу до невозможности.

Во-первых на рабочем месте у Вас нет и не может быть никакого личного пространства. Рабочий комп - это инструмент, выделенный Вам работодателем и он имеет полное право контролировать как Вы его используете.
И это его право заложено в ТК.
Во-вторых такое средство есть. Именно через браузер. Заходишь, выбираешь комп. Можно незаметно наблюдать за экраном - прямо видеть что человек делает. Или получить мгновенный скриншот. Или список процессов. Или еще кучу отчетов. При этом агента распознать на компе - ну, у нас админы этого не могут :)

Ключевое слово - Стахановец

Прям-таки совсем-совсем основной? И GC? И хозяин инфраструктуры? И мастер RID? И все это - вот так вот "выдохнули"? Ох и на...мучаетесь Вы... И это при том, что я фанат ОSS, а в самбу одно время даже патчи комиттил. Но все равно - так вот сплеча - SyavaSyava прав - проект наверняка провалится. Вводить ее надо дополнительным DC, посмотреть, как AD зацепится, как юзера мигрируют, а уж потом...может быть...

Сделать программиста админом своего компа. При этом предупредить его о том, что это несет с собой. Если контора достаточно бюрократизированная, получить от руководства служебку с подписями. Если нет - все равно предупредить, что если он разнесет свой комп, то восстанавилваться он будет в последнюю очередь.