Hello,
1: Add a conditional forwarder in DNS for adm-CustomAttributeText1, using adm-CustomAttributeText5
For this purpose you can use the example in the following article: http://itknowledgeexchange.techtarget.c ... one-types/ passing the necessary parameters using value references (e.g. %adm-CustomAttributeText1% or %adm-CustomAttributeText5%).
2: Register the new managed domain using adm-CustomAttributeText1,2(@1) and 3
Here's the script that should do the job. If you use several Adaxes services installed on different computers and joined to a configuration set, pay attention that credentials used by Adaxes to connect to domains are not replicated. This means, that you will have to register the domain on each of your services separately. In the script, $serviceAddress specifies the IP address or DNS host name of the Adaxes service where the domain is registered. Modify it to your requirements.
Also, pay attention that you should specify the DNS name of the domain that you want to register (e.g. domain.com). Flat domain names (like DOMAIN) or IP addresses are not allowed.
$serviceAddress = "localhost" # TODO: Modify me
# Bind to the Adaxes service
$admNS = New-Object "Softerra.Adaxes.Adsi.AdmNamespace"
$admService = $admNS.GetServiceDirectly($serviceAddress)
# Bind to the 'Managed Domains' container
$managedDomainsPath = $admService.Backend.GetConfigurationContainerPath(
"ManagedDomains")
$managedDomainsContainer = $Context.BindToObject("$managedDomainsPath")
# Create a new Managed Domain
$managedDomain = $managedDomainsContainer.Create("adm-ManagedDomain", "DC=%adm-CustomAttributeText1%")
try
{
$managedDomain.SetInfo()
}
catch [System.Runtime.InteropServices.COMException]
{
$Context.Cancel("The domain cannot be registered in Adaxes. " + $_.Exception.Message) # Cancels the operation if the domain object cannot be created (for example, if the domain is not available)
return
}
# Register the domain with the specified credentials
try
{
$managedDomain.Register("%adm-CustomAttributeText2%@%adm-CustomAttributeText1%", "%adm-CustomAttributeText3%")
}
catch
{
$Context.Cancel("The domain cannot be registered in Adaxes. " + $_.Exception.Message) # Cancels the operation if the specified credentials cannot be used to register the domain
return
}
3: Add an assigned over to a security role (One group will be used every time, assigned over adm-CustomAttributeText1)
7: Add an assigned over to a security role (The group created in step 5 over the business unit created in step 6)
Take a look at the following samples in our SDK: http://www.adaxes.com/sdk/?SampleScript ... Roles.html.
Also, take a look at Assigning a Role: http://www.adaxes.com/sdk/?ManagingSecu ... curityRole.
4: Create a Container under both Business Rules and Property Patterns called "name"
The following samples contain what you need:
5: Create a Group in the new manged domain under a specific OU called adm-CustomAttributeText8-CustAdmin
Take a look at section Creating Objects in the following SDK article: http://www.adaxes.com/sdk/?WritingAdsiS ... ateObjects
6: Create a Business Unit that includes by query filter adm-CustomAttributeText6 and 7
The following SDK article contains the necessary information: http://www.adaxes.com/sdk/?ManagingBusinessUnits.html.
8: Add the resultant OU from adm-CustomAttributeText6 to a Password Self-Service Policy
This can be done with the help of the IAdmPasswordSelfServicePolicy interface exposed by any Self-Service Policy object. The ActivityScopeItems property of the interface defines the Scope of Activity of the Policy. For information on how to define a Scope of Activity programmatically, see the following SDK article: http://www.adaxes.com/sdk/?DefiningScopeOfActivity.html.
9: Run winrm get winrm/config/client on the adaxes server and get the servers specified in TrustedHosts and then add adm-CustomAttributeText4
The following article describes how to do this in PowerShell: http://www.computerperformance.co.uk/po ... _wsman.htm.
10: Run script to create a credential file in C:\Credentials using adm-CustomAttributeText1,4,2@1,3 (NOT deleting old credentials)
As far as we understand, this is to be based on Citrix/terminalserver Logoff solution. In this case, here's the script block that deals with removing old credentials if they exist:
$filePath = $directory.FullName + "\" + $domainCSV.ComputerName
if((Test-Path -Path $filePath))
{
Get-Item -Path $filePath | Remove-Item -Force -Recurse
}
$file = New-Item $filePath -Type file
You can change it to something that can be done if credentials already exist. For example, you can just log a warning to Adaxes service log. Do not forget that in this case you should skip all the steps in the script that follow the block that removes old credentials. For example, if you include all the code that deals with generating files with credentials in your script to a separate function, then you can just exit the function with return.
$filePath = $directory.FullName + "\" + $domainCSV.ComputerName
if((Test-Path -Path $filePath))
{
$Context.LogMessage("Credentials for the specified domain already exist!", "Warning")
return
}
$file = New-Item $filePath -Type file
11: Add "adm-CustomAttributeText1\adm-CustomAttributeText8-CustAdmin" with access to the web interface "Help Desk" on ADAXES02 server and "adm-CustomAttributeText1\Domain Users" with access to the web interface Self Service on ADAXES02 server.
To modify access rules for Adaxes Web Interface, you need to modify the Web Interface configuration file. The file is called Web.config and it is located in the root directory of the Web Interface folder. By default, Adaxes Web Interface sites are installed to the following folders:
- Administrators:
C:\Program Files\Softerra\Adaxes 3\Web Interface\Admin\
- Help Desk:
C:\Program Files\Softerra\Adaxes 3\Web Interface\HelpDesk\
- Self-Service:
C:\Program Files\Softerra\Adaxes 3\Web Interface\SelfService\
This file needs to be accessed by Adaxes in order to perform the changes you need. So, if your Web Interface is not located on he computer where Adaxes service is installed, you'll probably need to share the folder for the Web Interface.
The Web.config is a standard XML configuration file. In the file, you can find the following XML element:
<authorization>
...
</authorization>
The subelements contained in this element define the users and/or groups that can access Adaxes Web Interface. For example, the following record means that the Web Interface can be accessed by users from groupA and groupB, and access to anyone else is prohibited (<deny users="?" /> denies access to unauthenticated users):
<authorization>
<deny users="?" />
<allow roles="DOMAIN\groupA"/>
<allow roles="DOMAIN\groupB"/>
<deny users="*" />
</authorization>
To manage the users/groups that are allowed/denied to use the Web Interface, you can use a specialized .NET API that for this purpose. Take a look at the description of the AuthorizationSection Class for detailed information and examples. Also, you can take a look at the following example: http://forums.asp.net/p/1502512/3557825.aspx. It is in C#, but can be easily converted to PowerShell.