Terminal Services Gateway Server Certificates

Замечательная штука в Windows 2008 - Terminal Services Gateway Server. Позволяет подключаться к организации извне по порту 443, не заморачиваясь виртуальными частными сетями и прочее. Но нигде не описана (я, по крайней мере, не нашел) такая особенность - клиент RDP 6.0 не поддерживает, в отличие от RDP 6.1, Wildcard certificates т.е. сертификаты типа (*.mydomain.com). Он не дает подключиться к серверу и кричит, что сертификат неверный. Если же ему поставить сертификат типа ts.mydomain.com, все замечательно. В клиенте 6.1 прокатывают оба варианта. Для совместимости, лучше все таки Wildcard не использовать (тем более, что даже в изначальной поставке Windows Vista стоит клиент 6.0)

LDAP Timestamp conversions

Два простеньких скрипта для преобразования LDAP Timestamps во время и обратно:

'---------- Ldap to Time --------------
intTime =inputbox("LDAP timestamp:")
intTime = intTime / (60 * 10000000)
intTime = intTime / 1440
WScript.Echo "Time: " & intTime + #1/1/1601#

'---------- Time to Ldap --------------
dtmTime =inputbox("Time:")
lngSeconds = DateDiff("s", #1/1/1601#, dtmTime)
str64Bit = CStr(lngSeconds) & "0000000"
WScript.Echo "Ldap timestamp: " & str64Bit

Скрыть OU в консоли Active Directory - Users and Computers

В числе прочих мер защиты критичных точек AD от вмешательства пользователей с повышенными привилегиями (например, младших системных администраторов), можно использовать сокрытие наличия определенных OU (например, содержащих учетные записи других администраторов). Скрыть OU из дерева просмотра можно, определив соответствующие разрешения (или запреты):



При таких разрешениях, пользователь Андрей Баранов не увидит в дереве OU Hide (если он будет внимателен, он увидит объект типа Unknown при просмотре корня AD). При этом, у него остается право читать свойства объектов внутри данной OU (если он, конечно, знает об этих объектах). Но, как я написал ранее, этот способ имеет смысл использовать в комбинации с другими способами защиты критичных объектов AD.

Отправка писем в VBS

Все время забываю, как это делается:

Слэш в свойстве объекта AD distinguishedName

Совершенно случайно столкнулся с проблемой - при попытке обратиться к объекту AD в строке типа Set objGroup=GetObject("LDAP://" & groupname) возникала ошибка типа E_ADS_BAD_PATHNAME (т.е. типа объект не найден, хотя в ADSI смотрю - вот же он!). Оказывается, слэш в distinguishedName (и некоторые другие символы) плохо воспринимаются при обращении к AD (т.е., например, слэш в названии группы). Какой же выход? Предварять все "опасные символы" обратным слэшем (т.е. строчка обращения к объекту должна выглядить приблизительно так:
Set objGroup=GetObject("LDAP://" & replace(groupname,"/","\/"))

Источник: http://blogs.dirteam.com/blogs/tomek/archive/2006/12/27/Slash-character-in-AD-object-distinguishedName.aspx

Система безопасности обнаружила попытку атаки для понижения роли сервера name. Учетная запись пользователя автоматически заблокирована

Внешние эффекты данной проблемы довольно забавные - как только пользователь входит в систему, его пароль блокируется из-за превышения числа попыток неправильного входа. Проблема была в том, что когда-то давно он ввел пароль при доступе к ресурсу, поставил галку "запомнить пароль", а затем благополучно этот пароль поменял.
Чтобы найти, где же все это хранится, надо написать в командной строке следующее:

rundll32.exe keymgr.dll,KRShowKeyMgr

Тут можно поглядеть, на что конкретно у нас сохранены пароли.

Источник: http://www.tweakxp.com/article37352.aspx

The IPSec driver has entered Block mode. IPSec will discard all inbound and outbound TCP/IP network traffic that is not permitted by boot-time IPSec..

Вот такое интересное сообщение возникает на машине, если файл локальных политик был случайно поврежден (например, некорректной перезагрузкой). Машина при этом не пингуется, не отвечает ни на какие запросы, но при этом вполне нормально работает. Временно обойти проблему можно, задизаблив службу IpSec. А корректно вылечить политику можно, удалив ветку реестра HKEY_LOCAL_MACHINE \SOFTWARE\ Policies\ Microsoft\ Windows \IPSec \Policy \Local и выполнив затем команду regsvr32 polstore.dll. В источнике, правда, описана ситуация с доменным контроллером, но с рядовым сервером тоже вполне сработало.

Источник: http://support.microsoft.com/kb/912023