a conversation with my buddies kwan thean keong and alexandre verkinderen got me started on looking into this particularly finicky integration pack. it seems that during the transition of opalis to microsoft, some things were lost in translation. this is an attempt to restore some of that but only so far as I've tested -- which admittedly, is not much.
requirements
first of all, let's talk about what you're going to need. one of the things lost apparently were some release notes that provided the much needed requirements that would have saved many an admin some hair and frustration. as stated in the provided help file for this intpack:
System requirements, installation, license, removal and known issues information is published in the Release Notes for this Integration Pack.
ah, but fortunately, the details were captured in this blog post. here is a synopsis.
System Requirements
Microsoft .NET 3.5 Framework
Windows PowerShell 1.0
Quest Powershell Commands (1.2) 32-bit to be installed on the Opalis Action Server.Quest PowerShell Commands for Active Directory can be obtained from Quest Software website at http://www.quest.com/powershell/activeroles-server.aspx . More information about Quest PowerShell Commands for Active Directory can be found from the Administrator’s guide at http://www.quest.com/QuestWebPowershellCmdletDwnldARS
The following commands can only be run on Windows 2008
New-QADPasswordSettingsObject
Get-QADPasswordSettingsObject
Add-QADPasswordSettingsObjectAppliesTo
Remove-QADPasswordSettingsObjectAppliesToIntegration Target Compatiibility
Microsoft Windows Server 2003 Domain
Microsoft Windows Server 2008 DomainOperating Systems
Microsoft Windows Server 2003 x86 Editions
- with Service Pack 1
- with Service Pack 2
Microsoft Windows Server 2008 32-bitIntegration Platform Compatiibility
Opalis Integration Server 5.52, 5.6, 5.6.1, 5.6.2, 6.0, 6.1, 6.2, and 6.2.2Operating Systems
Microsoft Windows Server 2003 x86 Editions
- with Service Pack 1
- with Service Pack 2
failure to install any of the prerequisites I mentioned above will cause a giant banner to flash upon your screen displaying the word "FAIL!". okay, seriously, if you miss them, the test connection properties will fail. that should be your first indication that something is wrong.
here we are at a most pleasing connection dialog for the AD intpack. I'm sure by now you're familiar with these dialogs if you've dealt with opalis at all. one thing to consider here is that you do not need to supply a server name unless absolutely required. you can simply supply your domain name. any client that understands srv records will know how to find the closest domain controller.
test the connection when you're done. that should get you started down the right path.
a little test
what's that you say? you encountered a problem even though your test connection was successful? well, as it turns out, so did i. let's take a look at a very simplified policy I was running through.
the second object should require no explanation. the custom start is simply supplying a parameter to reset user password named "username". the password itself was hardcoded to "password". I ran it, providing my test account as a username and received the following problem:
it's very difficult to read the context of the error summary like this, so I pasted it to notepad and included some artistic breaks for clarity. this is what we're working with in actuality.
The server is unwilling to process the request. (Exception from HRESULT: 0x80072035)
Command Executed [
$pwd=ConvertTo-SecureString -string "***************" -asPlainText -force
$connection=Connect-QADService -Service "myDomain" -ConnectionAccount "myDomain\myElevatedAccount" -ConnectionPassword $pwd
Set-QADUser -Identity "myTestUser" -UserPassword "*********" -Connection $connection
]
Command Executed [
$pwd=ConvertTo-SecureString -string "***************" -asPlainText -force
$connection=Connect-QADService -Service "myDomain" -ConnectionAccount "myDomain\myElevatedAccount" -ConnectionPassword $pwd
Set-QADUser -Identity "myTestUser" -UserPassword "*********" -Connection $connection
]
Please make sure you have Powershell and Quest Active Directory command installed on the Opalis Action Server
allow me to make the assertion that most likely the last line is not the problem you're encountering if you're to this point (unless your management server and action server are separated. it's wholly possible then.) the first thing I did was ran the commands through a powershell console to validate the opalis environment wasn't the issue. it wasn't.
if you recall, I hardcoded the password to "password". if you're operating in an environment with password complexity engaged, the quest cmdlets executed in this manner will not allow for overriding. to verify this, I changed the password to "#99bottles of BEER!%" and ran it through a powershell console and again through the opalis test console. the results are as follows:
success! keep in mind if you're using an object like generate random text that you're setting it properly so that it generates the right level of complexity for your organization.
Comments
Post a Comment