Может отдельный пользователь иметь несколько учетных наборов с помощью Active Directory MS
Одна опция состоит в том, чтобы использовать Системные события для отправки нажатия клавиши, необходимого для создания новой вкладки, но ограничение - то, что Вспомогательные Устройства в Универсальном Доступе должны быть включены и добавление, что задержка вида может быть необходимой.
tell application "System Events" to tell process "Terminal" to keystroke "t" using command down
Насколько я могу различить из Терминального словаря сценария - можно только получить информацию от вкладок, но не создать новые, как Вы могли с окнами (например, Выполнение действительно пишут сценарий "ясный"
Ответ на это в основном, нет. AD позволяет только один пароль на учетную запись пользователя. Поскольку AD имеет имя пользователя и пред2000 имен пользователя, я предполагаю, что Вы могли cludge вместе 2 имен пользователей для одной учетной записи, но не хорошая идея. Какая-либо конкретная причина Вам нужно это? Возможно, существует лучшее решение Ваших потребностей?
У Вас не может быть больше чем одного пароля, но у Вас может быть несколько имен пользователей с помощью нескольких расширений UPN.
т.е. для домена contoso.com у Вас могли быть логины: jim@contoso.com jim@fabrikam.com jim@whateverelse.com
Все они связанные с той же учетной записью. Однако у Вас все еще только был бы один пароль.
То, что Вы хотите сделать, изменяют Ваши клиенты для проверки аутентификации по двум источникам.
Другими словами, сохраните свою существующую базу данных, в то время как Вы переходите к Active Directory. Сделайте, чтобы клиенты проверили AD учетную запись и если это не делает автора, сделайте, чтобы они проверили подлинный источник прежней версии.
Любой ущерб, который Вы наносите, чтобы заставить AD принять несколько имен пользователей/паролей, будет чем-то, с чем Вы имеете дело в течение долгого времени. Просто идите параллельно источники аутентификационной информации, пока Вы все не перейдетесь.
-
1+1 для использования двойных источников аутентификационной информации, но я рекомендовал бы изменить сервер, не клиенты. Сделайте, чтобы клиенты продолжали отправлять учетные данные на сервер, как они делают, но на серверной стороне приложения, проверьте AD и затем источник прежней версии. Если клиентское приложение было абстрагировано от источника аутентификационной информации, Вы wouldn' t даже должен изменить клиенты, чтобы измениться как you' ре, проверяющее их учетные данные. – David Archer 25 June 2009 в 02:36
-
2David:Спасибо! я действительно не соглашаюсь с методом перехода, все же. Я думаю, что в долгосрочной перспективе, было бы лучше сделать, чтобы клиент прошел проверку подлинности непосредственно к AD. Это избавило бы от необходимости обслуживать две системы (AD источник и уровень абстракции), так как методы аутентификации являются not' t измененный так часто. That' s просто мое взятие, все же. Я могу быть неправым. – Matt Simmons 25 June 2009 в 03:50
Я не могу действительно видеть, почему у Вас была бы потребность сделать это, но я соглашаюсь с Sam, в котором нет никакого реального способа сделать это.
Можно скопировать пользователя или дать пользователю те же самые полномочия и даже доступ к тому же почтовому ящику и ресурсам и т.д., но я не вижу способ иметь несколько имен пользователей для одной учетной записи.
Active Directory не поддерживает то, что Вы описываете для единственного идентификатора безопасности (SID). Каждый SID может иметь точно одну комбинацию имени пользователя/пароля.
Можно сделать это функционально, к точке, путем создания объекта группы, в котором "jon1" и "jon2" являются оба участниками и использованием что группа во всех полномочиях (файловая система, почтовый ящик Exchange, и т.д.) касающийся "Jon Smith". (Необходимо использовать группы почти для каждого разрешения так или иначе.), Пока Вы не используете программного обеспечения, которое не может обработать SID группы, используемый вместо ни одного из SIDs от учетных записей пользователей Jon, которыми Вы будете очень хорошо.
Существует очень ужасный способ, которым Вы могли сделать это, но ПОЧЕМУ Вы захотите?
Идентификаторы Пользователя Active Directory являются действительно просто кратким способом определить учетную запись ее Настоящим именем, Идентификатором безопасности или SID. Каждый пользовательский объект имеет несколько атрибутов, присвоенных ему, который может использоваться для вхождения в систему с: samaccountname, Пользовательское имя принципала, и т.д. Они могли потенциально иметь различные значения, но у Вас все еще только будет Единый пароль. Вы могли "скопировать" пользователя через "Пользователей и Компьютеры" консоль MMC, которая гарантирует, чтобы обе пользовательских учетных записи имели те же составы группы и универсальные данные, но затем у Вас ВСЕ ЕЩЕ было бы два отличных пользовательских объекта с различными паролями. Они имели бы другой SIDs и будут считаться различными пользователями AD, хотя можно заставить их Выглядеть одинаково путем делания отчетов то же самое Отображаемое имя.
Если Вы ДЕЙСТВИТЕЛЬНО, ДЕЙСТВИТЕЛЬНО хотите повредить свой AD, можно попытаться использовать атрибут Истории SID для вставки дублирующегося SID в Каталог. Я настоятельно рекомендую, чтобы Вы не попытались сделать это. На самом деле Вам будет тяжело делать его, если Вы не будете ЧРЕЗВЫЧАЙНО знакомы с AD структурой и низкоуровневым программированием. Инструменты миграции Microsoft НЕ позволят Вам вставить дублирующийся SID в историю SID, поскольку это, как предполагается, уникальное значение атрибута. Я полагаю, что это может быть сделано, если Вы пишете свои собственные методы доступа в использовании MFC и переопределяете много встроенных гарантий. НО НЕ ДЕЛАЙТЕ ЭТОГО.