SSIS script component as a data source: используем скрипт для получения данных из нестандартных источников (например Active Directory)

1. Создаем Data Flow Task, Script Component как data source

Publishing an Exchange farm (OA) with KCD via TMG (Публикация фермы Exchange c KCD через TMG)

Симптомы достаточно странные. Опубликовал все, как полагается по инструкции на TechNet, все даже работает. Выглядит так:

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.

Слэш в свойстве объекта 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

Automatic certificate enrollment for local system failed to enroll for one Domain Controller certificate (0x80070005). Access is denied.

EventId: 13
Источник: AutoEnrollment
Automatic certificate enrollment for local system failed to enroll for one Domain Controller certificate (0x80070005). Access is denied.

В моем случае эта ошибка возникала на трех из четырех доменных контроллерах (кроме того, на котором стоял CA). Вылечилась добавлением группы Domain Controllers в группу CERTSVC_DCOM_ACCESS, после этого все контроллеры домена получают от CA свои сертификаты и довольны.