Now that the new NIST 800-63B guidelines are coming together, can Active Directory be updated to follow some of the guidance in here? Specifically allowing for blacklists of breached or otherwise bad passwords, potentially allowing for a salt to be added to AD password hashes, and rate throttling instead of just account lockout?

https://pages.nist.gov/800-63-3/sp800-63b.html

the value for the OperatingSystemVersion of Get-ADComputer cannot be properly referenced for Windows 10 Computers. The value shows as less than 2 and not more than 6.3. This command will list only Windows 10 computers: "Get-ADComputer -Filter {OperatingSystemVersion -lt "2"} -Properties * | ft dNSHostName,OperatingSystemVersion,OperatingSystem" When it should be something more like "Get-ADComputer -Filter {OperatingSystemVersion -ge "6.3"} -Properties * | ft dNSHostName,OperatingSystemVersion,OperatingSystem"

I would like to be able to output the SAN in a certificate with the command CertUtil.

the cmdlet get-certificate seems to do the job but only for the local store.

thanks

well, WTH?! ADUC lets you find users, computers, group, printers, shares, etc.

why on earth the new ADAC is lacking this feature? why don't you have the option to choose primitive object types in ADAC search as you can in ADUC? I know you have LDAP query builder and all that (which is awesome by the way); but shouldn't simple stuff be available and intuitive stuff be as easy as they have always been with newer tools?

we need a comprehensive syntax and semantics reference for Claims Rule Language. I know there are operators besides == ~= EXIST and such, which are not covered here. and this link is by far the most comprehensive which is available:
http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0-higher.aspx

Managing group memberships has always been a pain, and given the manual nature of managing security groups we tend to just leave them alone and let them multiply like rabbits. It would be awesome if Active Directory would finally after all these years introduce the concept of Security Groups that have dynamic membership based on, well, any other AD Attribute and support logic similar to the new ADFS Access Control rules

It's 2017 and there's still Server Software (even microsoft's own - like TFS), which is not able to handle gMSAs, because the password field is mandatory.
Since that software probably uses windows function to sign-in as such a user, it would be nice to have a mechanism, which allowed us to just use a dummy password for such an account - like "groupManaged" or "-" whatever else.

So perhaps this is possible, that Windows Server introduces a mechanism allowing to type a password in the mandatory password fields, which signalizes the same as an empty password for gMSAs.

The whatif switch is not working when installing a ADCS with the cmdlet Install-AdcsCertificationAuthority. The cmdlet is executed in full.
I blogged about it here:
https://mssec.wordpress.com/2016/02/18/installing-ca-via-powershell-whatif-not-working/
Jeffery Snover himself asked me on Twitter to submit a bug reort on this, see here:
https://twitter.com/jsnover/status/827524167465525249

If you have an OU name '1) Accounts' so the whole path is something like:
OU=1) Accounts,OU=sitename,DC=companyname,DC=com
New-ADUser -path will fail.
A workaround is to create the user and then move them later using something like:
Get-ADUser -Identity newuser | Move-ADObject -TargetPath OU=1) Accounts,OU=sitename,DC=companyname,DC=com

I would like the option to use LDAP Extended Controls with the Get-ADObject cmdlet.

As of Server 2016 you can use Get-ADGroup with -ShowMemberTimeToLive to see the TTL for expiring links or Get-ADObject with -IncludeDeletedObjects to include deleted objects.

However you can't use Get-ADGroup for Shadow Principals (used for Privileged Access Management) and Get-ADObject doesn't have the ShowMemberTimeToLive parameter.

So I suggest adding an ExtendedControls parameter to get Get-ADObject cmdlet, so you can pass the LDAP Extended Control OID you need to it.

At the very least add "ShowMemberTimeToLive" to Get-ADObject.

LDAP Extended Controls:
https://msdn.microsoft.com/en-us/library/cc223320.aspx

When viewing a group membership in ADUC, it would be extremely helpful to show additional columns like DisplayName and Description directly instead of having to open up each CN when our usernames/CN's are not friendly when they come from an enterprise provisioning system. The ability to directly see an account type, and name of user would allow us to remove people immediately without recursion.

Documentation is missing on what features require the Windows Server 2016 Functional Level and/or Schema Version 87.
- I found one mention in an Ignite presentation that said Windows Hello for Business requires Windows Server 2016 Functional Level.
-Conflicting old info on non-MS sites indicate Bastion forest needs to be Server 2016, but TechNet says 2012 R2 okay.

This link for 2016 Functional Level provides insufficient information.
https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/windows-server-2016-functional-levels

Please add support to use SQL Azure as DB. Would open up some easy HA scenario deployments for ADFS.

Right now in Windows Server 2012 R2 you are required to run present Domain Admin credentials while installing. This is not an option when AD FS and AD DS are supported by separate teams - it exposes domain admin credentials to persons which are not allowed to know them.
This was not a case for AD FS 2.0 - please remove the need of DA privileges to be entered at AD FS server.

Add the setting of ACL for domain join to "New-ADComputer" cmdlet.

In MMC it is possible to create an Computer AD Account and set "The following user or group can join this computer to a domain"

Would be nice to have it in New-ADComputer