Windows Server 2016 Active Directory-Detached Cluster - Cannot add a Client Access Point
How a client access point can be added to the cluster?


You'll have to use PowerShell. No AD means no AD and you lose all of the great functionality and brevity it offers.


  I need to add a client access point to use it later in SQL Server Availability Group Listener, to use it for auto-failover between mirrors.


Between replicas, you mean? Again, you'll need to use PowerShell.

There is an upcoming blog post [(placeholder)] blog post I wrote detailing this. When it is officially published, I'll update the answer with a link. In the interim, here is the basics of what you'll need to do this.

You may want to re-think using clusters like this (workgroup) as this is just the tip of the administrative iceberg you'll be dealing with.

Add-ClusterResource -Name "IPAddress1" -ResourceType "IP Address" -Group "WGAG"
Get-ClusterResource -Name IPAddress1 | Set-ClusterParameter -Multiple @{"Network" = "Cluster Network 1";"Address" = "20.250.250.9";"SubnetMask" = "255.0.0.0";"EnableDHCP" = 0}
Add-ClusterResource -Name "IPAddress2" -ResourceType "IP Address" -Group "WGAG"
Get-ClusterResource -Name IPAddress2 | Set-ClusterParameter -Multiple @{"Network" = "Cluster Network 2";"Address" = "30.250.250.9";"SubnetMask" = "255.0.0.0";"EnableDHCP" = 0}
Add-ClusterResource -Name "TestName" -Group "WGAG" -ResourceType "Network Name"
Get-ClusterResource -Name "TestName" | Set-ClusterParameter -Multiple @{"DnsName" = "TestName";"RegisterAllProvidersIP" = 1}
Set-ClusterResourceDependency -Resource TestName -Dependency "[IPAddress1] or [IPAddress2]"
Start-ClusterResource -Name TestName -Verbose


Updated with comments:


  ... now we are trying to setup cluster on SQL Server 2016 and Windows Server 2016 without AD (just to make everything simplier).


This does not make things simple. It actually creates much more manual of an environment. It is possible to automate things, but most of the common automation tools or powershell scripts aren't going to work as most assume either a standard login on each server (security issue) or implicitly use Windows Authentication which you now, won't have.

Additionally there is the aspect of SQL Server where you'll lose all the support of AD. No Kerberos, all SQL logins (or local windows logins - which are widely not useful in these scenarios) and no groups, etc. Setting up the AG will need to be completed through certificate endpoints if you want to keep things secure and you won't be able to use any GUIs in order to set it up end to end.

To reiterate, it doesn't make anything simple - only more complex. These types of configurations should only be used where they are expressly needed.

If you want to continue going this way, that's your prerogative... I can only give advice and answers.