Active Directory: как определить, является ли учетная запись служебной учетной записью? - PullRequest
0 голосов
/ 14 мая 2018

Вопрос: Можно ли определить, является ли учетная запись служебной учетной записью в Active Directory с использованием C # LDAP? Если да, то как?

Контекст: У меня есть программа, которая получает все объекты класса схемы типа USER, GROUP, COMPUTER, PRINCIPAL FOREIGN SECURITY и CONTACT. В настоящее время служебная учетная запись идентифицируется строкой, разбирающей каноническое имя для «служебной учетной записи». Мне не нравится это решение, потому что разбор строк зависит от расположения папки в иерархии, которая буквально говорит «учетная запись службы». Кажется возможным, что учетная запись службы может быть создана и затем помещена в путь к папке, который не содержит строку «учетная запись службы». К сожалению, я не могу это проверить, потому что я не являюсь администратором AD.

Я просмотрел онлайн без какой-либо удачи, поэтому я не уверен, возможно ли это вообще.

Обновление:

По Microsoft , похоже, что учетная запись службы содержится в objectClass msDS-ManagedServiceAccount. Однако, когда я установил для фильтра DirectoryEntry значение msDS-ManagedServiceAccount, результаты не возвращаются.

directoryEntry = new DirectoryEntry(strActiveDirectoryHost, null, null, AuthenticationTypes.Secure);
string strDsFilter = "(objectClass=msDS-ManagedServiceAccount)";

DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry)
{
    Filter = strDsFilter,
    SearchScope = SearchScope.Subtree,
    PageSize = intActiveDirectoryPageSize,
};

return searchResultCollection = directorySearcher.FindAll();

Ответы [ 2 ]

0 голосов
/ 02 ноября 2018

Так что я работаю над этим, чтобы получить MSA и создать их. Я могу получить MSA, используя пространство имен System.DirectoryServices.AccountManagement, все еще работая над его созданием (не уверен, действительно ли это возможно) Но для поиска учетных записей, которые являются MSA, вы можете использовать следующий код

PrincipalContext oPrincipalContext = new PrincipalContext(ContextType.Domain, sDomain, sDefaultOU, ContextOptions.SimpleBind, sServiceUser, sServicePassword);
GroupPrincipal currentGroup = GroupPrincipal.FindByIdentity(oPrincipalContext, "YourGroupName");
        foreach (Principal a_principal in currentGroup.GetMembers())
        {
            if (a_principal.StructuralObjectClass == "msDS-ManagedServiceAccount")
            {
                Console.Write(a_principal.SamAccountName); //To get the name
                ComputerPrincipal oComputerPrincipal = ComputerPrincipal.FindByIdentity(oPrincipalContext, a_principal.Name); //creating a computerprincipal to get more details about the MSA

            }
        }

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

 UserPrincipal oUserPrincipal = UserPrincipal.FindByIdentity(oPrincipalContext, sUserName);
      if (oUserPrincipal.StructuralObjectClass == "msDS-ManagedServiceAccount")
                {
                    Console.Write(oUserPrincipal.SamAccountName); //To get the samaccountname
                }
0 голосов
/ 15 мая 2018

Я тестирую ваш код, и он действительно возвращает результаты в моей среде.Несколько замечаний:

  • Убедитесь, что strActiveDirectoryHost отформатирован правильно.Формат должен быть LDAP://DC=contoso,DC=com
  • Проверьте, что вы ищете от корня (или достаточно высоко, чтобы найти учетные записи, которые вы ищете).MSA находятся под контейнером Managed Service Accounts в домене NC (т. Е. LDAP://CN=Managed Service Accounts,DC=contoso,DC=com)
  • . В моих тестах я звоню new DirectoryEntry() только с путем.Не уверен, что передача AuthenticationTypes.Secure вызывает у вас проблему
  • У вас есть правильный объектный класс.
...