wake-up-neo.com

UserPrincipals.GetAuthorizationGroups Beim Auflisten der Gruppen ist ein Fehler (1301) aufgetreten. Nach dem Upgrade auf den Server 2012 Domain Controller

Forschung:

Ein ähnliches Problem mit Problemumgehung, aber keine tatsächliche Lösung für das vorhandene Problem

Ähnliches Problem, das auf ein Microsoft End Point-Update als Täter hindeutet

Die oben genannten Links sind am besten für mein Problem geeignet. Ich habe auch alle ähnlichen, von Stack Overflow aufgelisteten Fragen beim Erstellen dieses Beitrags angesehen, und nur die oben genannten Fragen passen zu meinem Problem.

Hintergrund:

Ich habe UserPrincipal.GetAuthorizationGroups für Berechtigungen für einen bestimmten Seitenzugriff verwendet, auf dem IIS 7.5 auf Server 2008 R2 in einer C # .NET 4.0-Website für Webformulare seit zweieinhalb Jahren ausgeführt wird. Am 15. Mai 2013 haben wir einen primären Domänencontroller mit Server 2008 (nicht r2) entfernt und durch einen Server 2012-Domänencontroller ersetzt. Am nächsten Tag erhielten wir die unten aufgeführte Ausnahme.

Ich verwende Principal Context für die Formularauthentifizierung. Der Handshake "Benutzername/Pass" ist erfolgreich und das Authentifizierungscookie ist ordnungsgemäß festgelegt, der nachfolgende Principal Context-Aufruf, der auch UserPrincipal.GetAuthorizationGroups aufruft, schlägt zeitweise fehl. Wir haben ein paar BPA-Probleme gelöst, die im Server 2012 Domain Controller aufgetreten sind. Dies hat das Problem jedoch noch nicht gelöst. Ich habe auch einen Cron eingerichtet, der auf zwei separaten Servern läuft. Die beiden Server schlagen zu unterschiedlichen Zeitpunkten bei der SID-Auflösung der Gruppe fehl, obwohl sie dieselbe Codebasis verwenden. (Eine Entwicklungsumgebung und Produktionsumgebung).

Das Problem wird vorübergehend behoben, wenn der Webserver neu gestartet wird. Außerdem löst es sich auf dem Dev-Server nach 12 Stunden ohne Funktion auf. Der Produktionsserver funktioniert normalerweise bis zu einem Neustart nicht mehr ordnungsgemäß, ohne dass er sich selbst auflöst.

An dieser Stelle versuche ich, das Cron-Targeting für bestimmte Domänencontroller im Netzwerk sowie das neue DC zu verfeinern und die Standard-LDAP-Abfrage zu verwenden, die derzeit keine gezielteren Ausnahmezeiten liefert. Bisher haben wir auf einem Webserver festgestellt, dass es an den Tagen, an denen er ausfällt, kein Muster gibt, dass sich jedoch innerhalb von etwa 12 Stunden erholt. Die neuesten Ergebnisse zeigen, dass der SID-Auflösungsfehler der Gruppe zwischen 8.00 Uhr und 20.00 Uhr fehlgeschlagen ist. Nach einigen Tagen wird er um 20.00 Uhr ausfallen und um 8.00 Uhr wiederhergestellt. Anschließend wird er für weitere 12 Stunden fehlerfrei ausgeführt und schlägt erneut fehl. Wir hoffen, zu sehen, ob es sich nur um ein bestimmtes Problem bei der Serverkommunikation handelt, oder ob es sich um die gesamte Gruppe von Domänencontrollern handelt.

Ausnahme:

Exception information: 
Exception type: PrincipalOperationException 
Exception message: An error (1301) occurred while enumerating the groups.  
The group's SID could not be resolved.
at System.DirectoryServices.AccountManagement.SidList.TranslateSids(String target, IntPtr[] pSids)
at System.DirectoryServices.AccountManagement.SidList..ctor(SID_AND_ATTR[] sidAndAttr)
at System.DirectoryServices.AccountManagement.AuthZSet..ctor(Byte[] userSid, NetCred credentials, ContextOptions contextOptions, String flatUserAuthority, StoreCtx userStoreCtx, Object userCtxBase)
at System.DirectoryServices.AccountManagement.ADStoreCtx.GetGroupsMemberOfAZ(Principal p)
at System.DirectoryServices.AccountManagement.UserPrincipal.GetAuthorizationGroups()

Frage:

Hat jemand angesichts der oben genannten Informationen eine Idee, warum der Ausfall von Windows Server 2008 (nicht r2) und die Implementierung eines neuen Servers 2012 DC dazu führen würde, dass UserPrincipal.GetAuthorizationGroups mit dem 1301 SID-Auflösungsfehler fehlschlägt?. __ Ideen zur Beseitigung möglich Gründe würden auch geschätzt.

Haftungsausschluss: 

Dies ist mein erster Beitrag zu Stack Overflow. Ich recherchiere hier oft, habe mich aber bisher noch nicht an Diskussionen beteiligt. Verzeihen Sie mir, wenn ich woanders hätte posten sollen, und zeigen Sie mir, bevor Sie etwas posten.

UPDATE 13-JUN-2013:

Am 12. Juni ging ich auf die Möglichkeit ein, dass nicht angeordnete Gegenstände das Problem verursachten. Der Zeitrahmen war zu kurz, um festzustellen, ob der angepasste Code das Problem behoben hat, aber ich werde mich bei der Arbeit an einer Lösung weiter aktualisieren so dass vielleicht mit etwas Glück jemand hier helfen kann.

Ursprünglicher Code

    public bool isGroupMember(string userName, ArrayList groupList)
    {
        bool valid = false;

            PrincipalContext ctx = new PrincipalContext(ContextType.Domain, domain_server + ".domain.org:636", null, ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

            // find the user in the identity store
            UserPrincipal user =
                UserPrincipal.FindByIdentity(
                    ctx,
                    userName);

            // get the groups for the user principal and
            // store the results in a PrincipalSearchResult object
            PrincipalSearchResult<Principal> groups =
                user.GetAuthorizationGroups();

            // display the names of the groups to which the
            // user belongs
            foreach (Principal group in groups)
            {
                foreach (string groupName in groupList)
                {
                    if (group.ToString() == groupName)
                    {
                        valid = true;
                    }
                }

            }
        return valid;
    }

Aktualisierter Code

        public bool isGroupMember(string userName, ArrayList groupList, string domain_server)
        {
        bool valid = false;

            try
            {

                using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, domain_server + ".domain.org:636", null, ContextOptions.Negotiate | ContextOptions.SecureSocketLayer))
                {

                    // find the user in the identity store
                    UserPrincipal user =
                        UserPrincipal.FindByIdentity(
                            ctx,
                            userName);

                    try
                    {
                        // get the groups for the user principal and
                        // store the results in a PrincipalSearchResult object
                        using (PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups())
                        {
                            // display the names of the groups to which the
                            // user belongs

                            foreach (Principal group in groups)
                            {
                                foreach (string groupName in groupList)
                                {

                                    if (group.ToString() == groupName)
                                    {
                                        valid = true;
                                    }
                                }

                                group.Dispose();

                            }
                        }//end using-2
                    }
                    catch
                    {
                        log_gen("arbitrary info");
                        return false;
                    }
                }//end using-1
            }
            catch
            {
                log_gen("arbitrary info");
                return false;
            }

        return valid;

    }
27
Pynt

Ich bin gerade auf das gleiche Problem gestoßen und die Informationen, die ich gefunden habe, könnten hilfreich sein. Wie oben haben wir dieses Problem gesehen, bei dem der Domänencontroller Server 2012 ausführt - zunächst mit einer Kundenbereitstellung und dann in unserem eigenen Netzwerk repliziert.

Nach einigem Experimentieren stellten wir fest, dass unser Code auf Server 2012 einwandfrei ausgeführt werden konnte, aber der Fehlercode 1301 wurde angezeigt, wenn das Client-System Server 2008 ausführte. Die wichtigsten Informationen zu den Vorgängen wurden hier gefunden:

MS Blog aus dem Deutschen übersetzt

Der Hotfix, auf den in dem folgenden Link verwiesen wird, hat das Problem in unserem Testsystem behoben

SID S-1-18-1 und SID S-1-18-2 können nicht zugeordnet werden

Hoffe das ist hilfreich für jemanden! Wie viele bereits bemerkt haben, scheint dieser Methodenaufruf ziemlich fragil zu sein, und wir werden wahrscheinlich einen alternativen Ansatz implementieren, bevor wir auf andere Probleme stoßen.

Gary

18
Gary Hill

Hier ist meine Lösung. Es scheint konstant gut zu funktionieren. Da das Problem beim Iterieren der Sammlung auftritt, verwende ich beim Iterieren einen anderen Ansatz, um die Ausnahme zu behandeln, ohne die eigentliche Iteration zu blockieren:

private string[] GetUserRoles(string Username)
{    
    List<string> roles = new List<string>();
    try
    {
        string domain = Username.Contains("\\") ? Username.Substring(0, Username.IndexOf("\\")) : string.Empty;
        string username = Username.Contains("\\") ? Username.Substring(Username.LastIndexOf("\\") + 1) : Username;
        if (!string.IsNullOrEmpty(domain) && !string.IsNullOrEmpty(username))
        {
            PrincipalContext principalContext = new PrincipalContext(ContextType.Domain, domain);
            UserPrincipal user = UserPrincipal.FindByIdentity(principalContext, username);
            if (user != null)
            {
                PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups();
                int count = groups.Count();
                for (int i = 0; i < count; i++)
                {
                    IEnumerable<Principal> principalCollection = groups.Skip(i).Take(1);
                    Principal principal = null;
                    try
                    {
                        principal = principalCollection.FirstOrDefault();
                    }
                    catch (Exception e)
                    {
                        //Error handling...
                        //Known exception - sometimes AD can't query a particular group, requires server hotfix?
                        //http://support.Microsoft.com/kb/2830145
                    }

                    if (principal!=null && principal is GroupPrincipal)
                    {
                        GroupPrincipal groupPrincipal = (GroupPrincipal)principal;
                        if (groupPrincipal != null && !string.IsNullOrEmpty(groupPrincipal.Name))
                        {
                            roles.Add(groupPrincipal.Name.Trim());
                        }
                    }
                }
            }
        }
    }
    catch (Exception e)
    {
        //Error handling...
    }
    return roles.ToArray();
}
5
AlishahNovin

Wir hatten dieses Problem, als unser Infrastruktur-Team einen Domain Controller 2012 online stellte. Wir hatten auch vor dem Jahr 2012 DCs im Einsatz und so haben wir das Problem zeitweise erlebt. Wir haben ein Update gefunden, das ich teilen wollte - es hat 2 Teile.

Installieren Sie zunächst den von Gary Hill genannten hotfix . Dadurch wird das folgende Problem behoben:

Beim Auflisten der Gruppen ist ein Fehler (1301) aufgetreten. Die SID der Gruppe konnte nicht aufgelöst werden.

Wir dachten, dass wir nach der Installation dieses Hotfixes zu Hause frei waren. Nach der Installation wurde jedoch ein anderer zeitweiliger Fehler angezeigt. Bestimmte Gruppen, die wir befragten, hatten eine sAMAccountName-Eigenschaft. Die tatsächliche Eigenschaft wurde in Active Directory aufgefüllt, aber von der API wurde falsch ein Nullwert zurückgegeben. Ich gehe davon aus, dass dies ein Fehler in der Active Directory-API ist, aber ich weiß nicht mehr darüber.

Glücklicherweise konnten wir das Problem umgehen, indem wir die Gruppe Name-Eigenschaft anstelle der sAMAccountName-Eigenschaft verwenden. Das hat für uns funktioniert. Ich glaube, dass sAMAccountName effektiv veraltet ist und nur aus Gründen der Rückwärtskompatibilität existiert. Da dies der Fall war, schien es eine vernünftige Änderung zu sein.

Ich füge eine reduzierte Version unseres GetRolesForUser-Codes bei, um die Änderung an Ort und Stelle zu demonstrieren.

using (var context = new PrincipalContext(ContextType.Domain, _domainName))
{
    try
    {
        var p = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username);
        if (p == null) throw new NullReferenceException(string.Format("UserPrincipal.FindByIdentity returned null for user: {0}, this can indicate a problem with one or more of the AD controllers", username));

        var groups = p.GetAuthorizationGroups();
        var domain = username.Substring(0, username.IndexOf(@"\", StringComparison.InvariantCultureIgnoreCase)).ToLower();

        foreach (GroupPrincipal group in groups)
        {
            if (!string.IsNullOrEmpty(group.Name))
            {
                var domainGroup = domain + @"\" + group.Name.ToLower();

                if (_groupsToUse.Any(x => x.Equals(domainGroup, StringComparison.InvariantCultureIgnoreCase)))
                {
                    // Go through each application role defined and check if the AD domain group is part of it
                    foreach (string role in roleKeys)
                    {
                        string[] roleMembers = new [] { "role1", "role2" };

                        foreach (string member in roleMembers)
                        {
                            // Check if the domain group is part of the role
                            if (member.ToLower().Contains(domainGroup))
                            {
                                // Cache the Application Role (NOT the AD role)
                                results.Add(role);
                            }
                        }
                    }
                }
            }

            group.Dispose();
        }
    }
    catch (Exception ex)
    {
        throw new ProviderException("Unable to query Active Directory.", ex);
    }
}

Hoffentlich hilft das.

4
John Reilly

Ich habe den Fehlercode 1301 mit UserPrincipal.GetAuthorizationGroups bei der Verwendung einer brandneuen virtuellen Entwicklungsdomäne mit 2 Arbeitsstationen und 50 Benutzern/Gruppen (viele davon sind eingebaute). Wir haben Windows Server 2012 R2 Essentials mit zwei Windows 8.1 Enterprise-Arbeitsstationen ausgeführt, die der Domäne angehören.

Ich konnte mit folgendem Code rekursiv eine Liste der Gruppenmitgliedschaft eines Benutzers abrufen:

class ADGroupSearch
{
    List<String> groupNames;

    public ADGroupSearch()
    {
        this.groupNames = new List<String>();
    }

    public List<String> GetGroups()
    {
        return this.groupNames;
    }

    public void AddGroupName(String groupName)
    {
        this.groupNames.Add(groupName);
    }

    public List<String> GetListOfGroupsRecursively(String samAcctName)
    {
        PrincipalContext ctx = new PrincipalContext(ContextType.Domain, System.Environment.UserDomainName);
        Principal principal = Principal.FindByIdentity(ctx, IdentityType.SamAccountName, samAcctName);
        if (principal == null)
        {
            return GetGroups();
        }
        else
        {
            PrincipalSearchResult<Principal> searchResults = principal.GetGroups();

            if (searchResults != null)
            {
                foreach (GroupPrincipal sr in searchResults)
                {
                    if (!this.groupNames.Contains(sr.Name))
                    {
                        AddGroupName(sr.Name);
                    }
                    Principal p = Principal.FindByIdentity(ctx, IdentityType.SamAccountName, sr.SamAccountName);

                    try
                    {
                        GetMembersForGroup(p);
                    }
                    catch (Exception ex)
                    {
                        //ignore errors and continue
                    }
                }

            }
            return GetGroups();
        }

    }



    private void GetMembersForGroup(Principal group)
    {
        if (group != null && typeof(GroupPrincipal) == group.GetType())
        {
            GetListOfGroupsRecursively(group.SamAccountName);
        } 
    }

    private bool IsGroup(Principal principal)
    {
        return principal.StructuralObjectClass.ToLower().Equals("group");
    }
}
2
TS12

Ich befinde mich in einer Umgebung mit mehreren Domänen-Gesamtstrukturen und -Vertrauensstellungen. Ich habe fast genau denselben Code, der in einem Website-Formular ausgeführt wird, das zum Durchsuchen von Benutzersicherheitsgruppen in den verschiedenen Domänen verwendet wird. 

Ich erhalte diesen genauen Fehler in einer der sehr großen Domänen, in denen die Gruppenmitgliedschaft mehr als 50 verschiedene Gruppen umfassen kann. Es funktioniert gut in anderen Domänenwäldern.

In meiner Recherche habe ich einen Thread gefunden, der nicht verwandt wirkt, aber tatsächlich die gleiche Stack-Spur hat. Es ist für eine Remote-Anwendung, die auf SBS ausgeführt wird. Der Thread erwähnt, dass der Fehler durch nicht auflösbare SIDS in einer Gruppe verursacht wird. Ich glaube, dass es sich hierbei um sogenannte "Tombstoned" SIDS in Active Directory handelt. Siehe den Thread hier

Der Thread schlägt vor, dass das Auffinden der Tombstones-Enteries und das Entfernen aus den Gruppen das Problem lösen. Ist es möglich, dass Sie einen Fehler erhalten, weil SIDS alle 12 Stunden durch einen separaten, nicht zusammenhängenden Prozess Grabsteine ​​erstellt wird? Letztendlich glaube ich, dass dies ein Fehler im Framework ist und dass die Methode nicht aufgrund von veralteten/unauflösbaren SIDS abstürzen sollte.

Viel Glück!

1
Bri

Bei Interesse ist dies eine VB.NET-Version desselben Codes. Einige Dinge müssen Sie tun, bevor dieser Code funktionieren kann

1) Sie müssen auf die Assembly System.DirectoryServices .__ verweisen.
2) Stellen Sie sicher, dass Sie die Variable "theusername" ohne die Domäne übergeben. Wenn Ihre Domäne "GIS" ist und Ihr Benutzername "Hussein" ist, authentifiziert Windows Sie normalerweise als GIS\Hussein. Sie müssen also nur den Benutzernamen "Hussein" reinschicken. Ich habe die Groß- und Kleinschreibung herausgearbeitet .
3) Die Methode GetGroupsNew nimmt einen Benutzernamen und gibt eine Liste von Gruppen zurück
4) Die Methode isMemberofnew nimmt einen Benutzernamen und eine Gruppe und überprüft, ob dieser Benutzer Teil dieser Gruppe ist oder nicht. Dies ist der, an dem ich interessiert war.

Private Function getGroupsNew(theusername As String) As List(Of String)
    Dim lstGroups As New List(Of String)
    Try

        Dim allDomains = Forest.GetCurrentForest().Domains.Cast(Of Domain)()

        Dim allSearcher = allDomains.[Select](Function(domain)
                                                  Dim searcher As New DirectorySearcher(New DirectoryEntry("LDAP://" + domain.Name))

                                                  searcher.Filter = [String].Format("(&(&(objectCategory=person)(objectClass=user)(userPrincipalName=*{0}*)))", theusername)

                                                  Return searcher

                                              End Function)

        Dim directoryEntriesFound = allSearcher.SelectMany(Function(searcher) searcher.FindAll().Cast(Of SearchResult)().[Select](Function(result) result.GetDirectoryEntry()))

        Dim memberOf = directoryEntriesFound.[Select](Function(entry)
                                                          Using entry
                                                              Return New With { _
                                                               Key .Name = entry.Name, _
                                                               Key .GroupName = DirectCast(entry.Properties("MemberOf").Value, Object()).[Select](Function(obj) obj.ToString()) _
                                                              }
                                                          End Using

                                                      End Function)



        For Each user As Object In memberOf
            For Each groupName As Object In user.GroupName
                lstGroups.Add(groupName)
            Next
        Next

        Return lstGroups

    Catch ex As Exception
        Throw
    End Try
End Function

Private Function isMemberofGroupNew(theusername As String, thegroupname As String) As Boolean

    Try

        Dim lstGroups As List(Of String) = getGroupsNew(theusername)

        For Each sGroup In lstGroups
            If sGroup.ToLower.Contains(thegroupname.ToLower) Then Return True
        Next

        Return False


    Catch ex As Exception
        Throw
    End Try

End Function
1
Hussein Nasser

Ich hatte das Problem, dass wenn ich über VPN verbunden bin und groups=UserPrincipal.GetGroups() verwende, die Exception auftritt, wenn ich die Gruppen durchläuft.

Wenn jemand alle Gruppen eines Benutzers lesen möchte, gibt es folgende Möglichkeit (was schneller ist als die Verwendung von GetGroups()).

private IList<string> GetUserGroupsLDAP(string samAccountName)
{
    var groupList = new List<string>();
    var domainConnection = new DirectoryEntry("LDAP://" + serverName, serverUser, serverUserPassword); // probably you don't need username and password

    var samSearcher = new DirectorySearcher();
    samSearcher.SearchRoot = domainConnection;
    samSearcher.Filter = "(samAccountName=" + samAccountName + ")";

    var samResult = samSearcher.FindOne();
    if (samResult != null)
    {
        var theUser = samResult.GetDirectoryEntry();
        theUser.RefreshCache(new string[] { "tokenGroups" });

        var sidSearcher = new DirectorySearcher();
        sidSearcher.SearchRoot = domainConnection;
        sidSearcher.PropertiesToLoad.Add("name");
        sidSearcher.Filter = CreateFilter(theUser);

        foreach (SearchResult result in sidSearcher.FindAll())
        {
            groupList.Add((string)result.Properties["name"][0]);
        }
    }
    return groupList;
}

private string CreateFilter(DirectoryEntry theUser)
{
    string filter = "(|";
    foreach (byte[] resultBytes in theUser.Properties["tokenGroups"])
    {
        var SID = new SecurityIdentifier(resultBytes, 0);
        filter += "(objectSid=" + SID.Value + ")";
    }
    filter += ")";
    return filter;
}
0
Apfelkuacha

nach dem Upgrade des Domänencontrollers auf 2012 hatten wir ein ähnliches Problem. Plötzlich schlug mein Aufruf an user.GetAuthorizationGroups () fehl. Ich bekam dieselbe Ausnahme wie Sie (Fehler 1301). Also habe ich es in user.GetGroups () geändert. Das hat eine Weile gedauert, und dann fiel es gelegentlich aus, dass "falscher Benutzername oder Passwort" fehlschlug. Meine neueste Problemumgehung scheint das zumindest zu beheben. Anstatt eines davon aufzurufen, konstruiere ich nach dem Erstellen des Benutzerobjekts auch ein Gruppenobjekt, eines für jede Gruppe, in der ich sehen möchte, ob der Benutzer Mitglied ist. dh "user.IsMemberOf (group)". Das scheint zu funktionieren.

try
{
using (HostingEnvironment.Impersonate())
{
    using (var principalContext = new PrincipalContext(ContextType.Domain, "MYDOMAIN"))
    {
        using (var user = UserPrincipal.FindByIdentity(principalContext, userName))
        {
            if (user == null)
            {
                Log.Debug("UserPrincipal.FindByIdentity failed for userName = " + userName + ", thus not authorized!");
                isAuthorized = false;
            }

            if (isAuthorized)
            {
                firstName = user.GivenName;
                lastName = user.Surname;

                // so this code started failing:

                // var groups = user.GetGroups();
                // adGroups.AddRange(from @group in groups where 
                // @group.Name.ToUpper().Contains("MYSEARCHSTRING") select @group.Name);

                // so the following workaround, which calls, instead, 
                // "user.IsMemberOf(group)", 
                // appears to work (for now at least).  Will monitor for issues.

                // test membership in SuperUsers
                const string superUsersGroupName = "MyApp-SuperUsers";
                using (var superUsers = GroupPrincipal.FindByIdentity(principalContext, superUsersGroupName))
                {
                    if (superUsers != null && user.IsMemberOf(superUsers))
                        // add to the list of groups this user is a member of
                        // then do something with it later
                        adGroups.Add(superUsersGroupName);                                        
                }
0
David Barrows

Ich hatte die gleiche Ausnahme. Wenn jemand "LDAP" nicht verwenden möchte, verwenden Sie diesen Code. Weil ich verschachtelte Gruppen hatte, bin ich GetMembers (true) und es ist etwas länger als GetMembers ().

https://stackoverflow.com/a/27548271/1857271

oder laden Sie das Update von hier herunter: http://support.Microsoft.com/kb/2830145

0
Nazar Iaremii

Das gleiche Problem zu behandeln, Autorisierungsgruppen und die in der Antwort genannten Patches aufzählen, galt nicht für unseren Webserver. 

Das manuelle Aufzählen und Ignorieren der Probleme, die Gruppen verursachen, funktioniert jedoch gut:

private static bool UserIsMember(string usr, string grp)
{
    usr = usr.ToLower();
    grp = grp.ToLower();

    using (var pc = new PrincipalContext(ContextType.Domain, "DOMAIN_NAME"))
    {
        using (var user = UserPrincipal.FindByIdentity(pc, usr))
        {
            var isMember = false;
            var authGroups = user?.GetAuthorizationGroups().GetEnumerator();

            while (authGroups?.MoveNext() ?? false)
            {
                try
                {

                    isMember = authGroups.Current.Name.ToLower().Contains(grp);
                    if (isMember) break;
                }
                catch
                {
                    // ignored
                }
            }

            authGroups?.Dispose();
            return isMember;
        }
    }
}
0
davidmdem