Active Directory is used for more than just Windows Environments. Traditionally, scripting languages, such as python, have been used in the Linux space to perform automation against Active Directory. Now that PowerShell Core 6.0.X is GA, it would be great if the Active Directory module could be ported to be compatible with PowerShell Core and made cross-platform compatible. This would enable PowerShell based Active Directory management and automation possibilities from Linux, Mac, and IoT in addition to Windows.

Currently, PSSnapin dependencies in the AD module make it impossible to use in PowerShell Core. This leaves AD as one of the few modules preventing migration to PowerShell Core 6.X. With Windows PowerShell 5.1 now viewed as complete and PowerShell Core on a modern lifecycle, Windows PowerShell 5.1 will rapidly fall behind in feature set. With the AD Module Ported to PowerShell Core, automation and management tooling can take advantage of new features and fixes in the PowerShell language.

When we type in a computer in the search field, in ‘Active Directory Users and Computers’ Find ..., and forget to change to 'computer'. Then when we change it to computer it will clear the name box. with the message 'This will clear your current search result' Why? this have been bugging me for many, many years... so this is my user-voice :-)

I would like this behavior to change. Maybe just not to clear the box, and say nothing, and just change to computer.

Or there could be an option, to have the search filed be custom and remember the last choice. so that we can choose, the things we mostly search for, for me it would be Computers and Users.

Best regards
Dan

It would be incredibly helpful if Access Authorization Rules would allow the selection of a specific MFA Adapter or mechanism as a part of a ruleset.

For example, if a user was authenticating from a managed device, use certificate authentication, otherwise prompt for second factor using the Azure MFA adapter, or, if a user belongs to a specific group, always use certificate authentication forst, then attempt for Azure MFA, otherwsie if a user belongs to group "B", always prompt for the Azure MFA Adapter (or any other MFA provider integrated with ADFS)

At the moment it's an all-or-nothing option. If you have mroe than one adapter the user is prompted with all of them and asked to select their mechanism, which isn't very elegant.

There are way too many "dumb" LDAP implementations out there that simply can't deal with nested group memberships in AD. This makes it really hard to implement well organized RBAC in AD without a bunch of exceptions for the bad apps.

You can fool some of them with LDAP_MATCHING_RULE_IN_CHAIN if they give you enough access to configure the filters they're using. But others are simply stuck only caring about the flat list of users returned by the "member" attribute.

I envision a new constructed attribute on group objects called something like memberFlattened that basically has AD flatten the group member list and return that to the caller.

Meanwhile, I'll keep ******* my head against the wall trying to get software vendors to stop sucking.

Currently, if a browser-based user comes to the AD FS sign-in page, AD FS can only decide whether to use integrated authentication by looking at the browser's user agent string. However, t

There are cases where not all users arriving at the AD FS sign-in page can perform a Kerberos login - they might be within the IP range of the "internal" part of AD FS (in a split-brain DNS configuration) but the client may not be domain joined for various reasons, for example wireless users using BYOD. For these users Kerberos fails and it falls back to NTLM/Basic auth methods. The user receives an ugly popup box asking for credentials, with no context, branding, or guidance.

It would be better if this user was instead directed to the forms-based authentication method instead so that they received a recognisable sign-in experience (i.e. the same as if they were accessing externally).

Previously, this could be mostly worked around by setting a custom user_agent string for IE and using AD group policy to push it out to all domain-joined devices, however, with the move to Windows 10 and Edge as the preferred browser, this is no longer possible (Edge does not have a customisable user_agent string), so a choice needs to be made between turing on WIA for all users and accept that non-domain-joined devices will have a poor sign-in experience, or turn off WIA for all users except thouse using IE11 (dwindling population).

Possible solutions in order of preference:
1. Find a way to fall back to Forms-based auth if Kerberos fails
2. Often inability to perform WIA can be location-related, so introduce a new setting that would blackist certain network segments as being non-WIA compatible, and default to Forms-based for users accessing from those IP ranges
3. Allow Edge to have a customisable user_agent string controlled by group policy