[Kazun]

1. LDAP запрос - например LDAP bind request - http://msdn.microsoft.com/en-us/library/hh872036.aspx

Service logon - http://msdn.microsoft.com/en-us/libr...v=vs.85).aspx:
•A local or domain user account.
•The LocalSystem account.

Для учетной записи компьютера - собственно, как и для пользователя: аутентификация, обновление токена, смена пароля и т.д.

2. LastLogonTimeStamp - пусто, значит участник безопасности никогда не регистрировался в системе.

3. ms-DS-Logon-Time-Sync-Interval - если пусто, значит значение по умолчанию и равно 14 дней(если 0, то репликация отключена). И в статье это указанно:

The default value is 14 and is set in code. Meaning that if you look at this attribute in ADSIEDIT.MSC and you see it as "Not Set" don't be alarmed.

Код:

This just means the system is using the default value of 14

.

[nokogerra]

Добрый день, спасибо за ответ.

По поводу ms-DS-Logon-Time-Sync-Interval - я видел что при "не задано" используется значение по умолчанию, я просто тупой, не дошло что это атрибут домена, а не объекта-компьютера, у компьютера естественно такого атрибута нет (я не мог найти сам атрибут, а не его значение).

1. В указанной мной статье от Уоррена Уильямса указаны условия обновления атрибута lastLogonTimeStamp и они ясны, но не ясно - условия обновления атрибута lastLogon такие же (например, его значение для одного из компьютеров уже пару дней не меняется ни на одном КД и равно lastLogontimeStmap, так что похоже условия те же)? При этом похоже гипотетически возможна ситуация:

1й КД обслужил вход 1 январая, изменил lastLogon и изменил lastLogonTimeStamp и реплицировал его.

2й КД обслужил вход 8 января, его "прежний" LastLogon очень старый и он обновляет его значение, но условия для обновления lastLogontimeStamp не выполнены и получаем ситуацию, когда на одном из КД lastLogon больше чем lastLogontimeStamp. Такое может быть, верно? Хм, однако это похоже на правило 14 дней это не повлияет (имею в виду, что если ведется поиск неактивных машин в последние 90 дней, то стоит добавить 13 дней и искать по сроку 103 дня, чтобы гарантировано не задеть живые машины).

2. По поводу типов входа, которые форсируют изменение атрибута lastlogonTimeStamp - понятно, что любой интерактивный вход может спровоцировать обновление атрибута, но действует ли также прозрачная аутентификация, например в статье написано "browses a network share", скажем пользователю примаплен сетевой диск через GPP, но у сессии есть свой TTL, после его истечения должна быть прозрачная аутентификация, она тоже будет инициировать обновление атрибута?

По поводу компьютера мне вот что сказали:
"У билета Kerberos помимо срока обновления есть ещё и время жизни, по истечении которого билет обновить нельзя, и компьютер вынужден заново пройти аутентификацию на КД, чтобы получить новый билет.", т.е. lastlogon компьютера не зависит от включения/выключения компьютера. Полагаю это частично отвечает на мой предыдущий вопрос, но все же касательно пользователя речь в статье шла об интерактивном входе и просмотрах шар, а не о прозрачной аутентификации.