Твой предыдущий пост скушал бот-модератор поэтому отвечу тебе тут:Вот тебе RFC4120: https://www.ietf.org/rfc/rfc4120.txt
Ткни меня носом, где там UID-ы пользователей о говоришь. Kerberos Principal - бывает разный и типы у него бывают разные. Кстати, MS поддерживает только нотацию user@domain о чем написано даже на заборе^W в документации IBM: https://www.ibm.com/docs/en/db2/11.5?topic=authentication-na...
Покажи, в каком пакете у тебя KDC принимает UID особенно интересен пример с Windows.
SID формируются по стандарту, который описан и не менялся: https://learn.microsoft.com/en-us/openspecs/windows_protocol...
SID всегда включает в себя идентификатор Authority к котором относится субъект. Из-за этого v.pupkin@contoso.com и v.pupkin@fabrikam.com будут иметь разные SID, даже если у них случайно совпадёт RID. Это архитектурный дизайн такой. Оно специально делает так, чтобы не было случайных пересечений и не даёт тебе повесить никакие дополнительные права на SID, чей NT Account не известен. Что в этом такого страшного? Если тебе нужно выдать права внешнему пользователю, то тебе придется построить какие-то отшения доверия с его Authority.
В каком конретно "журнале ФС" у тебя появляются хвосты? Который в System Volume Information лежит или у тебя какой-то filter driver NTFS вякнул в журнал событий? Скинь пример того, о чем пишешь.
Если ты грохнул корень леса, а вместе с ним глобальный каталог домена, то не удивительно что у тебя не получается сопоставить SID с объектом каталога. Ничего удивительного.
> Маппинг нужен лишь для того, чтобы связать домены/системы работающие rfc2307 с теми доменами/клиентами, которые не смогли это осилить.
Нет, маппинг нужен всегда, где есть PAM, потому что операционная система, работающая с реализациями UNIX/Linux PAM понимает только локальную нумерацию и не принимает нумерацию из другого Authority без маппинга. И это как раз и есть главная проблема PAM. В нем всё исключительно локальной и сессии, и пользователи, вообще абсолютно всё. Winlogon при этом четко видит эту разницу и принимает SID из других доменов AD как есть, не пересчитывая число SID в локального пользователя. Нет ничего удивительного в том, что Windows потеряла возможность определять, где чей SID, если домен из которого она на себя применяла стал не доступен. "Windows AUTH", если ты имеешь в виду "Windows Authentication" или Negotiate тут вообще не при чем. Мне кажется ты не до конца понимаешь, о чем ты говоришь.
>В Windows пользователь вначале авторизовывается по NTLMv2, то есть обратившись к службе Logon в Windows, а потом уже с авторизационными данными получает билет Kerberos.
>Именно поэтому нельзя ввести Windows в домен FreeIPA.
Ну да, ты не понимаешь. Это просуществовало вплоть до 2003/XP. Оно осталось в староформатной аутентификации для RDS. Её иногда включают для старых тонких клиентов, но это не рекомендовано. При этом полный и окончательный переход на Kerberos, начавшийся в Vista/2008 закончился в 8.1/2012R2. Странно вообще такое читать. Ты мне рассказываешь про то, как NTLMv2 требуется для входа, а в мире Windows все последние годы с непривычки ныли, что начиная с 8 их принуждают пользоваться Kerberos везде и отжали не только NTLM, но и CredSSP.
Winlogon использует CredentialProviders: https://learn.microsoft.com/en-us/windows/win32/secauthn/win...
FreeIPA могла бы радостно написать свой очередной sssd для Windows, добавить его как службу и добавить провайдера. Вот только это никому не надо. NTLM тут вообще не при чем. Windows не может войти во FreeIPA, потому что там не та схема и не так входится в домен.
Кроме того, Windows не просто сразу идёт и получает TGT. Он кладёт его в кэш в LSA и автоматически запрашивает TGS при общении пользователя к известному сервису. Вообще сам процесс аутентификации пользователя - происходит сквозь учётную запись пользователя-компьютера. Она делегирует учетные данные, и на ней висит SPN. Раньше так делал NTLM, пока это не запретили.
Вот примеры маппинга для Windows:
- Маппинг NT Account и его SID в POSIX user и UID/GID для работы, например, с NFS.
- Маппинг NT Account в другой NT Account. Используется, например, при работе с WS-Management, когда внешнему (пусть даже доменному) пользователю ставится в соответствие локальная учетная запись, от лица которой он ходит на ФС и в другие части ОС. Это пример олицетворения (impersonation), и оно производится через сертификаты X.509.
В остальных случаях нужно использовать какие-то отношения доверия между Authority (Oauth2, SAML2, Kerberos).
Вместо того чтобы шутки-шутить, снабди свои сообщения реальными ссылками, а то кроме как дыры старого NTLM, который везде повыключали настолько, насколько это сейчас возможно это не находит. И конкретно ни SID, ни ACL тут ни при чем. Меня интересовали твои верификации и броадкасты, что ты этим называешь.
> Расскажи это MS, когда они требуют для построения доверия леса включить NTLMv1, так как NTLMv2 не поддерживает передачу SID нижнего по дереву в лесу домена.
Невозможность передачи SID между доменами без включения старых NTLM говорит о том, что у тебя либо слишком старый домен был, либо сломана аутентификация на Netlogon RPC, либо файрвол блочит рендж портов RPC. Случались такие проблемы на рубеже 2008R2/2012.
P.S. Мой тебе совет: если люди тебя не понимают, постарайся выражаться яснее. Я, вот, совершенно не понимаю, за что ты топишь. То тебе не нравится, что у учетной записи LocalSystem виртуальные SID могут быть ограничены в правах, то потом ругаешься, на NTLM и как там всё не безопасно. Так нужно ограничивать в правах или нет, определись уже.
S-1-5-18 NT AUTHORITY\SYSTEM - виртуальный пользователь для служебных нужд и нужд планировщика задач
S-1-5-32-544 BUILTIN\Administrators - это группа в которую входит LocalSystem
В Linux же тоже отжимают права у root постепенно методично и уже очень давно.
А пользовательский рендж 1-99 скорее соответствует S-1-5-32-... (BUILTIN). И всяким другим principals.
