none
Ошибка 80072020 при попытке выполнить LDAP-запрос из JScript RRS feed

  • Вопрос

  • Добрый день,

    Есть скрипт, с помощью которого выполняется заведение нового пользователя в домен Active Directory. Скрипт нужно запускать не от имени текущего пользователя, а от имени служебной уч. записи в домене, которой дано право добавить пользователя в домен. При выполнении скрипта (с  помощью команды RUNAS) и ввода пароля пользователя скрипт отрабатывает. Если же попытаться сделать это, передав пароль командой echo (echo "qwert12345"|runas ...), то скрипт валится на строке

    oADUsers = GetObject("LDAP://OU=test,DC=test,DC=test,DC=test");

    c ошибкой 80072020 ("Произошла ошибка операции")

    Может кто что подскажет?

     

    21 июля 2010 г. 13:49

Ответы

  •  

    Нашлось решение проблемы - это использование бесплатной утилиты CPAU (http://www.joeware.net/freetools/tools/cpau/index.htm)

     

    CPAU is an extremely popular tool. My original point in creating this tool was two fold, the ability to pass the password on the command line and to start up with network credentials versus local credentials. The first couldn't be done with RUNAS, the second required me to add an additional parameter and I was running RUNAS many times every day and was sick of typing /netonly.

    The use of this tool has gone through the roof. Unfortunately most people use it to enhance permissions on the local PC for logon scripts and other things like that so they are all stuck using the -profile or -lwp switches which force a local interactive logon. Note I said, stuck. That's right, I am not changing that functionality. When in doubt, type in -profile or -lwp. If you are trying to connect to a foreign machine with the enhanced permissions and the ID you are using can't be authenticated through the trust channels you will get an authentication error and you will know you need to get network credentials. If you are working in workgroup mode, you almost ALWAYS need network credentials instead of local credentials.

    Now there is one fun thing that people don't seem to get the hang of with network credentials. When you establish them, the password is NOT verified until you try to connect to something. So you can type in any password you want and it will fire up the process for you. When you go to touch the remote resource is when you will catch the error if you typed the password wrong, keep that in mind, it is important. Note that the program isn't broken, that is how it HAS to work.

    Another thing that confused people is security of network drives. When you spawn a process in another security context, you lose access to your current network drives. This is a security function Microsoft has been implementing. It wasn't the case in Windows NT and I know of no way to help you get it re-enabled because you can't. You should use UNC's as much as possible for connecting to remote file shares. See http://support.microsoft.com/kb/180362

    One function that people kept asking for that I eventually added was the ability to encode the userid, password, and command line to be executed in an encrypted file. I have done that but instead of dealing with the massive issues in making encryption work well for everyone I have set up a proprietary encoding algorithm that seriously obfuscates the information in the encoded file. Again, this is NOT strong encryption, this is text encoding. I will say that the encoding is pretty decent but I have no doubt that someone who was seriously interesting in cracking it certainly could given enough time, plus there are other underlying mechanisms available to anyone who really understands Windows API that can be used to get the userid and password being used. On the positive side there is a large use of random numbers in the encoded file and the same command with the same ID and password will not generate the same encoded file two times. This makes it much tougher to crack the file and few people are running around watching things running in debuggers.

     

    28 июля 2010 г. 13:33

Все ответы

  • AFAIK, вам не удастся передать в в команду runas пароль по конвейеру. Можно пойти другим путем: указать реквизиты доступа в саммо скрипте.

    http://blogs.technet.com/b/heyscriptingguy/archive/2004/12/13/how-can-i-run-a-script-under-alternate-credentials.aspx

    Хотя я бы все равно этого бы не делал. Запустить один раз cmd.exe от имени нужной учетной записи - не велика работа, а уж из этой консоли пускайте себе ваш скрипт столько раз, сколько вам нужно (всё лучше, чем в отрытом виде логин/пароль в скрипте прописывать).


    blog: http://shss.wordpress.com/
    • Изменено s.h.s. _ 21 июля 2010 г. 19:57
    21 июля 2010 г. 19:05
  • Хотя я бы все равно этого бы не делал. Запустить один раз cmd.exe от имени нужной учетной записи - не велика работа, а уж из этой консоли пускайте себе ваш скрипт столько раз, сколько вам нужно.

    Дело в том, что этот скрипт вызывается из win32 приложения. Т.е. этот скрипт запускает НЕ администратор. А приложение работает в контексте обычного пользователя, не обладающего необходимыми правами.
    21 июля 2010 г. 19:42
  • Хотя я бы все равно этого бы не делал. Запустить один раз cmd.exe от имени нужной учетной записи - не велика работа, а уж из этой консоли пускайте себе ваш скрипт столько раз, сколько вам нужно.

    Дело в том, что этот скрипт вызывается из win32 приложения. Т.е. этот скрипт запускает НЕ администратор. А приложение работает в контексте обычного пользователя, не обладающего необходимыми правами.


    не вижу никакой разниы. Оба варианта - в силе:

    1) Запускайте ваше приложение в конетксте нужного пользователя (run as).

    или

    2)Не важно, как вызывается скрипт. Важно, что это скрипт, а, значит, вы имеете возможность внести в него необходимые вам изменения.


    blog: http://shss.wordpress.com/
    22 июля 2010 г. 5:25
  • Я вообще не понял, зачем такие сложности. Вы можете делегировать пользователю право на добавление учетных записей в AD, и он сможет запускать скрипт от своего имени. Когда вы пытаетесь запустить скрипт с повышенными правами от имени другого пользователя, вы делаете тоже самое - делегирование прав, только этот способ не безопасный и сложный. Используйте делегирование прав и не осложняйте себе и пользователям жизнь.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    23 июля 2010 г. 2:33
    Модератор
  •  

    Объясняю с самого начала.

    Есть некоторое множество пользователей, которые работают с самописной программой (на Delphi). Эту программу они запускают каждый под своей уч. записью. Программа в себе содержит функционал управления собственными уч. записями. НО! При создании уч. записей требуется также продублировать это действие в Active Directory - чтобы пользователь с одинаковым логином/паролем был как в этой системе, так и в AD. Так вот нужно из программы создавать пользователей в AD, а делегировать сотням пользователям по стране такие права не хочется - а хочется, чтобы конкретно эта операция выполнялся из-под одной служебной учетной записи, логин/пароль которой никому не известен.

     

    23 июля 2010 г. 6:23
  • Если "логин/пароль которой никому не известен"="прописан в скрипте в открытом виде" ;), то ссылку я вам уже давал выше. Из вашего описания до сих пор не понятно, имеете ли вы возможность вносить изменение в скрип, создающий пользователя или нет.

    Существует другой способ, но он мало чем будет отличаться от делегирования (т.к. эти пользователи все равно получают возможность инициировать создание пользователя, хоть и не на прямую):

    Пусть ваша программа генерит некий файл в определенном формате, который, затем, она (программа) выкладывает на некую шару, доступную пользователю (работающему с вашей программой) на запись. На стороне сервера работает некий процесс в контексте пользователя, имеющего право на создание пользователя в AD. Этот процесс мониторит содержимое шары и, при появлении в ней файла заданного формата, обрабатывает его, создавая пользователя в AD. (Короче, получается работа через посредника или проксирование. Реализации могут быть разными)

     


    blog: http://shss.wordpress.com/
    23 июля 2010 г. 7:55
  • Да, изменения в скрипт вносить можно.

    Конвеерная передача пароля из бинарника для этого и использовалась (echo "qwert12345"|runas ...), чтобы не писать в скрипте тот самый логин-пароль служебной уч. записи.

    Еще один способ - идти вообще другим путем - делать добавление пользователя не через скрипт, а писать целый бинарный модуль добавления пользоватеktq средствами Delphi... :(

    23 июля 2010 г. 9:15
  • >Конвеерная передача пароля из бинарника для этого и использовалась (echo "qwert12345"|runas ...), чтобы не писать в скрипте тот самый логин-пароль служебной уч. записи.

    Ну, в конце концов, вы можете передавать логин пароль внутрь скрипта в качестве параметров вызова оного скрипта, если вам так больше нравится. (В этом случае пароль будет храниться в открытом виде не в скрипте, но в бинарнике)


    blog: http://shss.wordpress.com/
    • Предложено в качестве ответа s.h.s. _ 28 июля 2010 г. 9:37
    • Отменено предложение в качестве ответа Сергей Алексеев 28 июля 2010 г. 13:30
    23 июля 2010 г. 9:33
  •  

    Нашлось решение проблемы - это использование бесплатной утилиты CPAU (http://www.joeware.net/freetools/tools/cpau/index.htm)

     

    CPAU is an extremely popular tool. My original point in creating this tool was two fold, the ability to pass the password on the command line and to start up with network credentials versus local credentials. The first couldn't be done with RUNAS, the second required me to add an additional parameter and I was running RUNAS many times every day and was sick of typing /netonly.

    The use of this tool has gone through the roof. Unfortunately most people use it to enhance permissions on the local PC for logon scripts and other things like that so they are all stuck using the -profile or -lwp switches which force a local interactive logon. Note I said, stuck. That's right, I am not changing that functionality. When in doubt, type in -profile or -lwp. If you are trying to connect to a foreign machine with the enhanced permissions and the ID you are using can't be authenticated through the trust channels you will get an authentication error and you will know you need to get network credentials. If you are working in workgroup mode, you almost ALWAYS need network credentials instead of local credentials.

    Now there is one fun thing that people don't seem to get the hang of with network credentials. When you establish them, the password is NOT verified until you try to connect to something. So you can type in any password you want and it will fire up the process for you. When you go to touch the remote resource is when you will catch the error if you typed the password wrong, keep that in mind, it is important. Note that the program isn't broken, that is how it HAS to work.

    Another thing that confused people is security of network drives. When you spawn a process in another security context, you lose access to your current network drives. This is a security function Microsoft has been implementing. It wasn't the case in Windows NT and I know of no way to help you get it re-enabled because you can't. You should use UNC's as much as possible for connecting to remote file shares. See http://support.microsoft.com/kb/180362

    One function that people kept asking for that I eventually added was the ability to encode the userid, password, and command line to be executed in an encrypted file. I have done that but instead of dealing with the massive issues in making encryption work well for everyone I have set up a proprietary encoding algorithm that seriously obfuscates the information in the encoded file. Again, this is NOT strong encryption, this is text encoding. I will say that the encoding is pretty decent but I have no doubt that someone who was seriously interesting in cracking it certainly could given enough time, plus there are other underlying mechanisms available to anyone who really understands Windows API that can be used to get the userid and password being used. On the positive side there is a large use of random numbers in the encoded file and the same command with the same ID and password will not generate the same encoded file two times. This makes it much tougher to crack the file and few people are running around watching things running in debuggers.

     

    28 июля 2010 г. 13:33