MVV

Но в таком случае ему нужно давать доступ на чтение всего корневого каталога, я верно понимаю?

Неверно. Есть специальное разрешение для таких случаев - "Чтение содержимого папки". Дайте этому сотруднику (или, лучше, группе, в которой он состоит, можно такую сделать специально для него) это разрешение на все папки по пути от той, к которой дан общий доступ, до нужной ему. А если еще для общей папки включено перечисление на основе доступа (оно в Windows есть уже лет пятнадцать), то он ещё и ничего лишнего не должен увидеть.

Вообще говоря, никак: подсистема безопасности не знает ничего о пользователях другого компьютера и как их аутентифицировать.
Со стороны клиента можно попробовать сохранить (в "сохраненных учетных данных) учетные данные (имя и пароль) для пользователя, созданного на сервере, чтобы подключение шло по его имени. Ещё вариант - создать на сервере пользователя с тем же именем и паролем, что и тот, под которым работает программа на клиенте и надеяться, что клиент будет подключаться чисто по имени и паролю. Но это - совершенно без гарантии.

https://learn.microsoft.com/en-us/previous-version...

Есть хорошее под названием WebDAV. Это - протокол доступа к файлам, работающий поверх HTTP (и HTTPS). В WImdows серверная часть реализуется одним из компонентов IIS (обычно его надо устанавливать/активировать отдельно). Ну, а ещё через WebDAV Sharepoint мог работать. Клиент WebDAV встроен в Windows, начиная с XP (надеюсь, его ещё не выпилили) как редиректор (клиентский компонент сети Microsoft) - то есть, папки и файлы по WebDAV доступны как обычные файлы и папки на сетевом диске. Когда-то (не в курсе за сейчас) по WebDAV можно было даже c файлохранилищами типа Яндекс-диска работать.
PS Порты NetBIOS и SMB настолько часто используются всяческими вирусами, что многие провайдеры для клиентов на тарифах для физлиц блокируют их. Вероятно, поэтому вам и не удалось их открыть.

Сервер DHCP может быть где угодно. Но он обычно раздает адреса серверов DNS для клинтов. И для работы AD это критично. Общее правило: на клиентах в списке серверов DNS не должно быть серверов, которые не знают про домен AD. В списке серверов DNS должны быть только контроллеры домена (КД) или серверы/прокси DNS, которые переадресуют запросы к именам из этого домена на КД.
Простейший вариант этого правила, для начинающих: в списке серверов DNS на членах домена должны быть только КД.

Ошибка - не в протоколе доступа (SMB), а в аутентификации/авторизаци.
Для поиска включите (если не включен) на сервере аудит удачных и неудачных попыток входа в систему, и смотрите, под каким пользователем идут попытки подключения.
Если под анонимным - проблема в аутентификации. Т.к. при подключении по IP используется только NTLM, то смотрите, чтобы на клиенте и на сервере использование NTLM не было ограничено политиками и на ошибки от Сетевого входа в систему (NetLogon) в журнале Система на сервере.
Если под конкретным пользователем, то для начала смотрите, под ожидаемым ли пользователем происходит вход. Если нет - разбирайтесь на клиенте, нет ли там сохраненных учетных данных для взода на сервер. Если да -смотрите в политиках, на наличие у него прав на вход в систему по сети: входит ли он в группу тех, кому доступ разрешен, и не запрещен ли доступ персонально ему (это две независимые настройки).

Через групповую политику: Конфигурация компьютера/Административные шаблоны/Система/Дисковые квоты

Включите аудит доступа. Проще всего он включается через политику.

В настройках dhcp распространяю выдачу ip адресов, указываю dns домен-контроллера (*.10.1) и основной шлюз (*.10.2)

Так делать нельзя: клиенты по Windows в каждый момент работают с одним сервером DNS (по крайней мере - при елинственном подключении сети), на другой они переключаются при недоступности первого.
Настраивайте в качестве сервера DNS для клиентов только КД (точнее, сервера DNS на нем), а для самого КД обеспечьте возможность разрешения имен в общемировом DNS. Если не хотите разрещать ему доступ к любым серверам DNS в интернете (кстати, почему?), используйте DNS-сервер или DNS-прокси на шлюзе: настройте его как сервер пересылки в консоли сервера DNS в Windows.
Для п.3 вам требуется прокси-сервер. Какой - не посоветую: что там сейчас на какой платформе модно (и вообще поддерживается) - я не в курсе.

я поднял 1й КД (dc1), установил ему адрес 192.168.88.2, и в dns добавил 1 запись, самого себя.

Когда КД в сети больше одного, то так делать не надо. Добавляйте на него второй DNS на DC2. Иначе есть возможность, что содержимое зон DNS на обоих КД будет рассогласовано (впрочем, для вас, судя по в вашему описанию, эта возможность - теоретическая, но все равно стоит делать хорошо сразу).

решил глянуть статус репликации, а там ошибка
ошибка репликации

Прямо сейчас там ошибок нет: все разделы каталога среплицировались. Но проверьте обратную репликацию на DC1 - она совершенно отдельная, мало ли что там.
Те сообщения, которые вы видите - это пока не забытые прошлые ошибки (например, при старте AD). Или такое бывает, если команда была запущена не в режиме администратора.

PS А вообще состояние КД лучше проверять командой dcdiag (из командной строки в режиме администратора). Если не хотите читать лишние буквы - используйте dcdiag /q, тогда будут выведены только тесты с ошибками.

Уберите 8.8.8.8 из всех списков серверов DNS на всех клиентах, которым нужно обращаться к домену (на NAS, в частности). Этот сервер почти наверняка не способен разрешать имена ваших КД в IP вашей локальной сети (подробности разных сценариев опускаю). По умолчанию DNS на КД вполне способен справляться с разрешением всех имен (и из интернета - тоже, через корневые сервера). Если это вдруг не так - кто-то (ваш маршрутизатор или провайдер) почему-то блокирует исходящие запросы DNS с КД - настройте на них пересылку запросов на внешний сервер DNS, запросы на который не блокируются (например, тот же 8.8.8.8).
PS Если маршрутизатору не нужно обращаться к домену (в том числе - если он настроен как DNS Proxy для локальной сети), то 8.8.8.8 можно оставить, чисто на случай отказа всех КД.

Судя по симптомам, наиболее вероятная проблема - изначальная неисправность репликации SYSVOL, препятствующая этому КД объявить себя таковым. Перезапустите на каждом КД службу репликации DFS (она же DFSR) и смотрите наличие в его журнале событий ошибок или предупреждений в течение 15 минут после перезапуска. Дальнейшие действия зависят от того, что там зафиксировано.

PS Официальные рекомендации от MS по аналогичным проблемам: https://learn.microsoft.com/en-us/troubleshoot/win...

Если вам нужно подключиться самому для администрирования сервера - попробуйте для подключения запустить mstsc /admin: подключитесь в режиме администрирования, без запроса лицензии, но число таких подключений ограничено (ЕМНИП до сих пор 2-мя).

Если у вас установка свежая и ещё не в бою, считаю предпочтительным вариант выше, от Роман Безруков .
Но есть альтернатива, которую можно попробовать: загрузиться в безопасном режиме восстановления службы каталогов (надеюсь пароль для этого режима у вас есть) и переименовать компьютер обратно, как было. После чего - помолиться своему богу или постучать по дереву и попробовать перезагрузиться.
PS

Помимо разрешений на папку:
1. Убедитесь, что папка и файлы внутри нее не открыты по сети (в узле "Общие папки\Открытые файлы"в консоли управления компьютером, например).
2. Убедитесь, что у вас есть разрешения на удаление всех подпапкох и файлов на все подпапки внутри этой папки (имейте в виду, что наследуемые разрешения могут и не примениться, т.к. разрешения хранятся для кажого файла или папки отдельно).

Начать надо с того, что сервер времени - это часть конфигурации компьютера, а не пользователя (кстати, это видно на картинке по вашей ссылке). Поэтому посмотрите результат применения политик (RSOP) к компьютеру, для этого результат лучше всего вывести в файл: gpresult /scope computer /h файл.htm

Проверьте (например, командой ping) на сервере AD разрешение имен DNS для сайтов, которые находятся в интернете. Если оно не работает - настройте так, чтобы оно работало. Как именно настроить - завист от причины. Например, если запросы DNS наружу от сервера AD режутся у вас на маршрутизаторе - разрешите их: сервер DNS на сервере AD по умолчанию уже настроен на поиск в DNS, начиная с корневых серверов, и дальше в соответствиеи с делегированием, а чтобы этот поиск работал, нужно чтобы запросы проходили.
Если запросы DNS к посторонним серверам (кроме своего) режет провайдер - настройти на сервере DNS для AD в его свойствах безусловную пересылку на сервер DNS провайдера.

Я так понимаю у меня не находит сервис из-за задваивания "looch.local" в запросе.

Наоборот, запрос к имени с к нему дописанным суффиксом домена ("задваивание") происходит потому, что перед этим на запрос к самому имени клиенту приходит ответ, что имя не найдено.

Как я понял, у вас это 172.16.128.1 - это микротик? Если да, тогда подозреваю, что его адрес отдавается по DHCP клиентам в качестве второго сервера DNS, а на самом микротике условная пересылка запросов к домену AD DNS на контроллер домена AD (КД) не настроена. Так? Если так (это - распространенная ошибка), то либо уберите микротик из списка серверов DNS, либо настройте на нем нужную условную пересылку (если это возможно и если вы это умеете). Потому что клиент, в какой-то момент может переключиться на этот второй сервер DNS на микротике (например, при сбое при обращении к DNS на КД), а микротик ничего про ваш домен AD не знает - вот и получается эта ошибка.