Я не знаком с Убежищем, поэтому, пожалуйста, простите за потенциальную неопределенность этого ответа. Я много работал с NAnt, и все, что выполняется (задачи, execs и т. Д.), Имеет потенциал для работы в интегрированном режиме аутентификации.
В конце концов, аутентификация передается тому, кто запускает родительский процесс NAnt. При этом, это может быть признаком того, что задачи Vault в NAnt не поддерживают встроенную аутентификацию? Это означает, что если vaultsetloginoptions задача требует аргументов пользователя и пароля, то нет хорошего способа передачи учетных данных (как вы указали).
Если не будет обходных путей для потенциала, которого не хватает в задачах Vault для NAnt, можно использовать задачу <exec
> для вызова версии их командной строки инструмент на стороне клиента (даже не уверен, есть ли он). Если это опция, встроенная аутентификация автоматически включается, если пользователь, выполняющий процесс NAnt, совпадает с пользователем, которому необходимо подключиться к Vault.
Нам пришлось сделать это для нескольких вещей, с которыми мы интегрируемся в процесс сборки. Мы либо выполнили exec'd для версии командной строки, либо написали свои собственные задачи, расширив инфраструктуру NAnt. В любом случае, это должно быть возможно.
Обновление
Некоторые осматривали форумы Vault, и кажется, что интеграция AD - это просто способ заставить Vault Client запрашивать пользователя и передавать его на сервер. С форума :
Клиент Vault всегда будет запрашивать
для имени пользователя / пароля. Наше объявление
интеграция ограничена сервером
проверка того, что пароль введен
соответствует паролю в Active
Каталог.
Следовательно, для клиента нет истинного способа передавать информацию проверки подлинности Windows встроенным способом. Клиентская программа Vault требует ввода имени пользователя и пароля при работе в режиме AD. К сожалению, казалось бы, без сохранения имени пользователя / пароля шансы на интеграцию seamless NAnt - это далеко.