PrincipalSearcher for machine local users is case sensitive

[bigbearzhu]

Hi all,

When finding users with PrincipalSearcher.FindAll method for machine context, it seems the search is case sensitive. However if the search is for domain users, it becomes case insensitive. The reason for this is because domain search is using LDAP which is case insensitive. But machine local search goes through SAMQuerySet which uses a regex that doesn't take in RegexOptions.IgnoreCase.

Would it be safe to add that option so that the search behavior is consistent across different context types? Thanks

[danmoseley]

Is it the same on desktop framework?

[bigbearzhu]

I actually found this issue in ASP.Net App targeting .Net Framework. However I cannot find public repo contains System.DirectoryServices.AccountManagement source code for .Net Framework. Although decompiled code shows exactly the same code. That’s why I raised it here. Sorry if it is not the right place.

[danmoseley]

@bigbearzhu it's fine, just curious whether it was .NET Core specific. Sounds like not. Fixes we make here are considered for porting to .NET Framework.

[bigbearzhu]

That is awesome! Should I send a pull request or someone else will do? Sounds like a really simple fix but not sure how safe it is. No idea how this would be unit-tested as this is fundamental framework code. Thanks.

On 3 Feb 2018, at 4:31 pm, Dan Moseley notifications@github.com wrote:

@bigbearzhu it's fine, just curious whether it was .NET Core specific. Sounds like not. Fixes we make here are considered for porting to .NET Framework.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[danmoseley]

@tarekgh sounds comment on your proposed change.

[tarekgh]

@tquerec can comment on this.

[ViktorHofer]

But machine local search goes through SAMQuerySet which uses a regex that doesn't take in RegexOptions.IgnoreCase.

You propose to change the local search behavior from case sensitive to case insensitive, is that right? If so, I'm not sure this isn't a breaking change as you could get more results back than before. We should check if there's documentation that outlines the current behavior.

[tarekgh]

CC @josephisenhour @bongiovimatthew-microsoft @tquerec

[sachinpandey122]

Hi all, do we have any conclusion on this yet? Thanks,

[webatxcent]

I am not sure why this issue has any push back. The local security authority will not let you create two user accounts with the same name regardless of case. Performing a case insensitive search shouldn't return any more results. Is this a fix that could be forth coming?

[danmoseley]

@joperezr (since you have more context on this area now) -- thoughts? is this simply wrong and an easy fix?

[danmoseley]

Also this comment just above I believe is no longer accurate. We can release DynamicMethods, so RegexOptions.Compiled does not cause unbounded growth. (It does add startup time though so it's not necessarily a good thing, but if throughput matters more then it's a good thing)

            // Ideally, we'd like to use a compiled Regex (RegexOptions.Compiled) for performance,
            // but the CLR cannot release generated MSIL.  Thus, our memory usage would grow without bound
            // each time a query was performed.

[joperezr]

The one I'm very familiar with is System.DirectoryServices.Protocols which in Windows it is just implemented on top of wldap32 which means for all searches it uses the LDAP protocol search, which as this issue points out it is case insensitive. AccountManagement namespace is a bit more complex since it supports more specific types of directories like ADDS, ADLDS, and MSAM which is the one that seems to have the case sensitive issue here. I'm not too familiar with that so as @tarekgh suggested, I would like to know what does @tquerec think about this one as MSAM might have some different characteristics unlike traditional ADDS.

[tquerec]

@joperezr I believe this is just a bug in the API. MSAM ( local account store ) is case insensitive so the regex should be updated to be case insensitive.

[simon-biber]

Is there any workaround to find users in the local machine quickly and with case insensitive usernames?

For AD users we are using:

                return UserPrincipal.FindByIdentity(context, domainBackslashUserName);

but that is very slow for Machine users - I have read it's a NetBIOS timeout per network adapter - so we are using the following which is much faster for the local machine:

                using var user = new UserPrincipal(context);
                user.SamAccountName = username;
                using var searcher = new PrincipalSearcher(user);                
                return searcher.FindOne() as UserPrincipal;