This request is Add a custom field option for Subject Name format for "Build from this Active Directory information" on a user certificate template.

Build from this Active Directory information is an important feature for many companies using Active Directory Certificate services as it ensures the user account can't create their own values on a certificate , which could mis-represent the identity and create security concerns. This is also an important option used for auto enrollment of user certificates.

Currently the only options for this section are Common Name or Fully Distinguished name or None.

This Feature request is to add a custom field option to "Build from this Active Directory information" for a user certificate template so that an admin can add other AD attribute values for Subject Name.

The AD attribute value would use a <> delimiter, like this
<AD Attribute>

to notate the AD attribute and also to allow combining values or other text parameters.
This is similar to other ADCS settings that can create CRL publishing values for example. If the AD Attribute is empty the certificate could be expected to fail as other values that may be missing on a user certificate template.

For example, if we want just the DisplayName to be added to subject name, the admin only would enter in <DisplayName> in the custom field.
If the admin wanted to just add in SamAccountname, the admin would put in that value <Samaccountname> into the custom field.

If the admin wants to combine values with other text , they could enter it in using the delimited AD attribute values with whatever other custom text they would want to add.

Example 1
If the admin wants to have a user's givenName and surname attributes with a space between each value as the certificate subject, they would enter it into the custom field like so:
<givenName> <sn>

So if user's givenName value was Joseph and sn was smith, the above cert would show a subject of:
Joseph Smith

Example 2
If the admin wanted a - in between Displayname and samaccountname, they could do this

<DisplayName>-<Samaccountname>
If the user's Display name is Joseph Smith and their samaccountname is abc123 the cert subject name would be

Joseph Smith-abc123

Feature Request Background

The reasons for this request is that AD Common name or DN's may not be in a format that makes it easy to read the certificate names for a person. A company may have very unique values for CN that may not look human friendly.

For example, take the example of a very large company. There may be 1000 John Smith's or many name change operations to perform. To create uniqueness the AD common name may have more random values, for example JS123456 versus Joseph Smith. The effect of this is particularly impactful for document signing that displays the certificate subject name which may look random to a user. Someone reading the signed data may see the Subject name and think that it is not Joseph Smith, as users may not inspect on other attributes in the certificate (for example, email,etc).

I have a team of engineers working towards PowerShell Modules that we need to upload to PowerShell. We have a work group email address for our team. We would like to use this group email address to upload our modules. I spent quite some time on Azure Active Directory but it only allows me to login using my work email address. I do not see any option to create an account with group email address or add it anywhere. We have done the same using "Manage Organization" feature in nuget.org for our nuget packages. Please help since we do not want to use our individual work email addresses while uploading packages and making future releases.

Their exists a scenario with ADFS and SSO based apps (to include 365) where there is a common user logged into their PC but need to access their webmail. However it detect the user logged and and wants to leverage WIA. Current work around is to do a REGEX and push user agent string to those impacted PCs to not perform WIA and results in Forms Auth. However with Microsoft pushing Edge and Chromium going towards client hints, this bandaid is slowly loosing its adhesive.

Ideally it would be nice to specify a group and force them to forms based auth in lieu of WIA. That plus a link to include private mode and then users could log in and check mail, etc while staying logged into the endpoint via the common kiosk account

When I try to use Get-Help with any of the aboutActiveDirectory* topics, it just gives me a list of cmdlets. Other topics, like aboutFor or about_Break work as expected. I had originally thought it was perhaps an interop issue with PowerShell 7 being installed as well, but it happens when I try it on my Domain Controller that has only the PS built in to the server. An example is below:

PS C:\Windows\system32> Get-Help -Name about_ActiveDirectory

Name Category Module Synopsis

Get-ADAuthenticationPolicy Cmdlet ActiveDirectory Gets one or more Active Directory Domain Services authentication policies.
Get-ADAuthenticationPolicySilo Cmdlet ActiveDirectory Gets one or more Active Directory Domain Services authentication policy silos.
Get-ADCentralAccessPolicy Cmdlet ActiveDirectory Retrieves central access policies from Active Directory.
Get-ADCentralAccessRule Cmdlet ActiveDirectory Retrieves central access rules from Active Directory.
Get-ADClaimTransformPolicy Cmdlet ActiveDirectory Returns one or more Active Directory claim transform objects based on a specified filter.
Get-ADClaimType Cmdlet ActiveDirectory Returns a claim type from Active Directory.
Get-ADComputer Cmdlet ActiveDirectory Gets one or more Active Directory computers.
Get-ADDomainController Cmdlet ActiveDirectory Gets one or more Active Directory domain controllers based on discoverable services criteria, search parameters or by providing a domain controller identifier, such as the NetBIOS name.
Get-ADFineGrainedPasswordPolicy Cmdlet ActiveDirectory Gets one or more Active Directory fine grained password policies.
Get-ADGroup Cmdlet ActiveDirectory Gets one or more Active Directory groups.
Get-ADObject Cmdlet ActiveDirectory Gets one or more Active Directory objects.
Get-ADOptionalFeature Cmdlet ActiveDirectory Gets one or more Active Directory optional features.
Get-ADOrganizationalUnit Cmdlet ActiveDirectory Gets one or more Active Directory organizational units.
Get-ADReplicationConnection Cmdlet ActiveDirectory Returns a specific Active Directory replication connection or a set of AD replication connection objects based on a specified filter.
Get-ADReplicationSite Cmdlet ActiveDirectory Returns a specific Active Directory replication site or a set of replication site objects based on a specified filter.
Get-ADReplicationSiteLink Cmdlet ActiveDirectory Returns a specific Active Directory site link or a set of site links based on a specified filter.
Get-ADReplicationSiteLinkBridge Cmdlet ActiveDirectory Returns a specific Active Directory site link bridge or a set of site link bridge objects based on a specified filter.
Get-ADReplicationSubnet Cmdlet ActiveDirectory Returns a specific Active Directory subnet or a set of AD subnets based on a specified filter.
Get-ADResourceProperty Cmdlet ActiveDirectory Gets one or more resource properties.
Get-ADResourcePropertyList Cmdlet ActiveDirectory Retrieves resource property lists from Active Directory.
Get-ADResourcePropertyValueType Cmdlet ActiveDirectory Retrieves a resource property value type from Active Directory.
Get-ADServiceAccount Cmdlet ActiveDirectory Gets one or more Active Directory managed service accounts or group managed service accounts.
Get-ADTrust Cmdlet ActiveDirectory Returns all trusted domain objects in the directory.
Get-ADUser Cmdlet ActiveDirectory Gets one or more Active Directory users.
New-ADObject Cmdlet ActiveDirectory Creates an Active Directory object.
Set-ADAuthenticationPolicy Cmdlet ActiveDirectory Modifies an Active Directory Domain Services authentication policy object.
Set-ADAuthenticationPolicySilo Cmdlet ActiveDirectory Modifies an Active Directory Domain Services authentication policy silo object.
Set-ADComputer Cmdlet ActiveDirectory Modifies an Active Directory computer object.
Set-ADFineGrainedPasswordPolicy Cmdlet ActiveDirectory Modifies an Active Directory fine grained password policy.
Set-ADGroup Cmdlet ActiveDirectory Modifies an Active Directory group.
Set-ADObject Cmdlet ActiveDirectory Modifies an Active Directory object.
Set-ADOrganizationalUnit Cmdlet ActiveDirectory Modifies an Active Directory organizational unit.
Set-ADServiceAccount Cmdlet ActiveDirectory Modifies an Active Directory managed service account or group managed service account object.
Set-ADUser Cmdlet ActiveDirectory Modifies an Active Directory user.

One change to security for incorrect password entry that would make it friendlier for the users and more secure against brute force password attacks would be to use a geometrically increasing delay when a specific number of wrong passwords are entered. The first delay could be one minute, the second 5 minutes, the third 25 minutes, the fourth 125 minutes, etc. Of course this would also involve a time setting for resetting the wrong passwords progression after a previous delay. This would make the initial delay for wrong passwords very short for the user, but would increase the time for a brute force attack to guess the possible passwords from months to years.

When adding values in a multi-value field (such as the serialNumber attribute), the editor sorts by alphabetical order. When adding values via PowerShell, order is the order in which they were inserted.

The order in which the editor displays is not a filter, but modifies the true order (to where even PowerShell displays them that way). Without this order, the positions are useless. One could use a MV field like a simple one row spreadsheet (using ordering like column positions). The only way to make it useful is by making it a key/value pair (e.g. model:12345), and this basically defeats the purpose of the multi-value datatype.

My company uses O365, AD FS 2016 and Azure AD, recently our internet provider had repeated outages where the AD FS servers access to the internet was compromised. This was a unavoidable outage for users on our internal network but since O365 leveraged Azure MFA in a CA policy external users could not get to O365 resources because they could not do MFA at ADFS. I want to create a plugin that checks for access to Azure MFA if it fails it places a default hardcoded claim in the token package validating MFA but raising a RIsk factor whtich will allow Business continuance.

Currently the only possibility to check the time and creator of a user is to check the audit logs for event 4720. Storing creation and modification date-time for an AD user is great but when the creatorsName & modifiersName information is absent, it becomes a burden.

Also RFC 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models suggests these too.

"...

  Entries may contain, among others, the following operational attributes:


  - creatorsName: the Distinguished Name of the user who added this

      entry to the directory,

  - createTimestamp: the time this entry was added to the directory,

  - modifiersName: the Distinguished Name of the user who last

      modified this entry, and

  - modifyTimestamp: the time this entry was last modified.

..."

It's possible to extend the schema and add this information through a third party application. But as long as it was not a native feature, it would create trouble, especially for migrations.