Forum Discussion
flipa_29928
Nimbostratus
NimbostratusService Account Not recognised During MP Instal
Hi All,
I have tried to install the F5 Management Pack to the RMS server following the instructions on this site but at the point in the installer wizard where I am prompted to supply the Service Account credentials for the account that will run the f5 Monitoring service an error message appears with the following message:
"Application attempted to perform an operation not allowed by the security policy. To grant this application the required permission, contact your system administrator, or use the Microsoft .NET Framework Configuration tool.
If you click Continue, the application will ignore this error and attempt to continuee.
Logon failure: unknown user name or bad password"
The Details of the error message then go on to list the following messages:
"************** Exception Text **************
System.Security.SecurityException: Logon failure: unknown user name or bad password.
at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
at F5Networks.ManagementPack.Setup.SetupUI._AuthenticateServiceAccount()
at F5Networks.ManagementPack.Setup.SetupUI.Next() at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
The Zone of the assembly that failed was: MyComputer"
This is followed by more output listing the Loaded Assemblies at the time of the error.
This error occurs regardless of whether I use the specially created F5 Service Account or the SCOM Admin account.
I am also confused as to why the above output should indicate "MyComputer" as a zone whatever that means.
By way of context I should mention that the F5 Service Account has been added to a SCOM Admins global security group and I have also explicitly added it to the Local Admins on the SCOM database server. The account that I use when running the F5 MP Installer is the SCOM Admin account which is an admin of the RMS and of the SCOM application itself so the permissions should be there to complete the task even if I had to resort to using the SCOM Admin account as the F5 Service Account out of desperation to get through the installer.
If anyone has seen a similar error and found the resolution or can decipher what this error means and what exactly I need to do in the .NET Framework Configuration tool to allow the service account to be recognised I would be grateful.
Thanking you for your considered rely,
flipa.
10 Replies
- Hi Flipa,
Are you logged in locally or with a domain account while you're attempting to install the F5 Management Pack? Or, are you attempting to run the F5 Management Pack installation wizard from a network share? If yes, just copy and run the setup file locally, on your SCOM management server. Can you please attach (or email managementpack(at)f5(dot)com) the setup.log file found in \Program Files\F5 Networks\Management Pack\log folder? This could possibly give us more information about the error.
Thank you.
Julian
(F5 Management Pack Team) 
flipa_29928Hello Julian, I am logged in with my SCOM Admin account which a domain account.
If my understanding of the F5 MP documentation is correct this account should by definition have the required privileges to server as the “Installation account” that will allow me to install the F5 MP suite and then I can specify the separate F5 Service Account in the installation wizard.
Given that neither the F5 Service Account nor the SCOM Admin account seemed to be able to get past this error message in the screen and based on a quick Google search of the NET framework Configuration Tool and what it is used for it seems I may need to change some settings in the .NET Framework of the RMS (which is also the Web Console server and therefore running IIS to allow the account(s) to be authorized to make changes to the IIS web server insofar as some components of the F5 MP Suite touch the web console server component of the RMS.
Please correct me if I am mistaken in this assumption?
Looking through the Setup.log file I can see that it has a lot of information pertaining to our environment which I am not comfortable to release.
The last paragraph of output from the Setup.log file however prior to the installer cancelling contains the following lines:
==================
Info: Found .NET framework installed: v3.5 SP
Info: Started installation of the F5 Networks Management Pack 2.1.5.440. Info: msi logging parameters: /lwecma!
Info: System Center Operations Manager 2007 R2 (Version 6.1.7221.0) found.
Info: Extracted msi to a temp directory. Running the F5 Networks Management Pack installation.
Info: The current installation was canceled.
Please let me know if the above lines are of use or if you require more from the setup.log output.
Are there any guidelines relating to .NET Framework configuration application or security settings that I may have missed to enable the installer to complete given that the RMS is also hosting the SCOM Web console role?
With thanks for your assistance,
Michael- Hello Michael,
Thank you for your detailed response. I'll try to best answer your questions:
1. Do some components of the F5 MP Suite touch the web console server component of the RMS?
No. The components deployed with the F5 MP are mostly .NET assemblies and they're not binding to, nor referencing web / IIS modules. Some modules however rely on SCOM dependencies, but nothing related directly to SCOM's web server modules.
2. Are there any guidelines relating to .NET Framework configuration application or security settings that I may have missed?
No, nothing special. The F5 MP deployment requires a standard configuration of the .NET Framework (v2.0 or higher), which would be part of any current Windows Server platform.
As you also sensed, I do believe that you may have a .NET runtime security policy that may prevent the successful execution of the F5 MP installer. Please do the following:
1. Copy the F5 MP installer file (F5Networks.ManagementPack.Setup.exe) somewhere locally on the system (the SCOM management server where you run the installer from).
2. Open a command prompt window on the SCOM management server where you run the F5 MP installer from.
3. Verify the Code Access Security policy on the F5 MP installer: caspol -rsp F5Networks.ManagementPack.Setup.exe (make sure to enter to right path to the executable).
4. You should be getting an output similar to:Microsoft (R) .NET Framework CasPol 2.0.50727.4927 Copyright (c) Microsoft Corporation. All rights reserved. Resolving permissions for level = Enterprise Resolving permissions for level = Machine Resolving permissions for level = User Grant = PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" Success
I would be interested to find out if you have the "Unrestricted" permission on the F5 MP installer.
Let us know and we'll take it from there.
Julian - flipa_29928HI Julian,
Thanks for the troubleshooting advise.
After pottering around trying to locate the caspol.exe tool in the correct x64-bit version of the .NET Framework folder I was presented with the following output:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727>caspol -rsp D:\Temp\F5Networks.ManagementPack.Setup-2.1.5.440-
x64\F5Networks.ManagementPack.Setup-2.1.5.440-x64\F5Networks.ManagementPack.Setup.exe
Microsoft (R) .NET Framework CasPol 2.0.50727.4016
Copyright (c) Microsoft Corporation. All rights reserved.
Resolving permissions for level = Enterprise
Resolving permissions for level = Machine
Resolving permissions for level = User
Grant =
version="1"
Unrestricted="true"/>
Success
C:\Windows\Microsoft.NET\Framework64\v2.0.50727>^Z
So it looks like the setting appears to match the example you provided.
Just to be doubl-sure I tried running the 32-bit version of the toll as well with the following results:
C:\Windows\Microsoft.NET\Framework\v2.0.50727>caspol.exe -rsp D:\Temp\F5Networks.ManagementPack.Setup-2.1.5.44
0-x64\F5Networks.ManagementPack.Setup-2.1.5.440-x64\F5Networks.ManagementPack.Setup.exe
Microsoft (R) .NET Framework CasPol 2.0.50727.4016
Copyright (c) Microsoft Corporation. All rights reserved.
The assembly at D:\Temp\F5Networks.ManagementPack.Setup-2.1.5.440-x64\F5Networks.ManagementPack.Setup-2.1.5.44
0-x64\F5Networks.ManagementPack.Setup.exe cannot be loaded. Caspol can make a partial determination of what e
vidence would be associated with this assembly. If this evidence is used, the results are not necessarily acc
urate or complete. Would you like to continue this operation using partial evidence? (yes/no)
yes
Resolving permissions for level = Enterprise
Resolving permissions for level = Machine
Resolving permissions for level = User
Grant =
version="1"
Unrestricted="true"/>
Success
C:\Windows\Microsoft.NET\Framework\v2.0.50727>
Are above permissions settings adequate?
With thanks,
Michael - Michael,
I think we've been poking in the wrong direction. On a second thought, looking back to your initial post and the error about the logon failure and related security exception context, I think it all comes down to the security profile associated with the account that you're passing into the setup wizard, for the F5 Monitoring service account. You said you get the error, regardless if you're using the designated service account for the F5 Monitoring Service or the 'SCOM admin account'.
Let's just focus on the designated service account to run the F5 Monitoring Service. There's no other magic going around in the F5 MP setup about the error you get, other than trying to create a WindowsIdentity instance with the service name you're providing. To take the F5 MP setup wizard completely out of the picture, please open up a PowerShell command window on the management server where you try to run the F5 MP setup on, and type the following code into it:$wi = New-Object 'System.Security.Principal.WindowsIdentity' 'account_name'; Write-Host $wi.Name;
This code basically attempts to create a new windows identitiy for the account in question (replace account_name with your service account designated for the F5 Monitoring Service). The output should either give you the domain name of the account or give you the same error you're getting while running the F5 MP setup.
If you still get the error, you'll have to somehow figure out why the account you're passing in may not have a valid name. If the script above returns a valid name, please pass the exact name as you got from the output, into the F5 MP wizard.
Julian - flipa_29928Hi Julian,
When I enter the above command in a PowerShell CLI on the RMS making sure to substitute the service account for the 'account_name' parmater I get the following result:
New-Object : Exception calling ".ctor" with "1" argument(s): "Logon failure: unknown user name or bad password.
"
At line:1 char:17
+ $wi = New-Object <<<< 'System.Security.Principal.WindowsIdentity' 'F5_service_account'; Write-Host $wi.Name;
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
The weird thing is that the same result occurs whether I pass the SCOM Administrator service account or event my own username which is a local Administrator on the server. It seems no matter what account I use the result is the same error.
Michael - flipa_29928Hi Julian,
I have managed to get past the error message that pops-up whenever I enter the credentials for the F5 monitoring Service Account in the installer wizard by asking one of my Domain Admins to attempt to launch the installer with a Domain Admin level user account.
This time, the installer wizard did not complain and we were able to see the summary screen that indicates "The F5 Networks management Pack is ready to Install" so it seems that the issue is not the service accounts that I had specified were incorrect but that the installer needs to run using a Domain Admin level account.
This seems to be borne-out by the Installation Tutorial video that I watched in which the demonstrator right-clicks the F5 MP Installer icon and selects Run As and then enters a Domain Admin user account for his test lab.
In my own test-lab where the installer worked the account I was logged-in with when I ran the installer was also a Domain Admin though I was not aware of this at the time. I was under the impression that it was just the Builtin Local Administrator account but now I am told it was in fact a Domain Admin account.
In the Documentation for the F5 Networks Management Pack there does not appear to be any explicit reference to the installer needing to be run using a Domain Admin level account.
To quote the Installing the F5 management Pack document:
User Accounts
You will want to make sure you have access to the following two accounts.
•Installation Account -
This is the account you will use to install the F5 Management Pack with. This account should have local system administrator privileges, SQL administrator privileges, and Operations Manager Administrator privileges.
•Service Account -
This is the account you will specify to run the F5 Monitoring Service as. This account must be in a group that is specified in the Operations Manager Administrators in the Operations Manager Console under Administration->Security->User Roles->Operations Manager Administrators. It is recommended that you create a separate Active Directory group for this purpose if you have not done so already. This user is also required to be a local system administrator and a SQL administrator.
So, my next question to this forum is if anyone can provide me with the reason why this installer needs to use a Domain Admin level account in order to run?
It is one thing if the installer could run using a local Administrator account that only modifies one server but as the installer seems to need a Domain Admin account one would assume that the installer is attempting to write to the Domain which is not something that you allow without knowing exactly what it is that the installer is doing.
From a Change Management perspective knowing what exactly the installer does that requires it to be run with a Domain Admin account is extremely important in my environment so if anyone in the product team is able to respond I would be grateful as it would assist me in getting approval to run the installer with such an account.
With thanks for all replies,
flipa - Hi Flipa,
Thank you for your detailed feedback. The installation account privileges are the one we should be focusing on here and in particular the "Local System Administrator Privileges" for the account, considering the actual error that you're getting. If the account that you are trying to install with does NOT have local administrator privileges on the box, you'll be getting the error. Also, you'll be getting this error if any of the following conditions exists in your local / domain environment
1. The computer is not attached to a Windows 2003 or later domain.
2. The computer is not running Windows 2003 or later.
3. The user is not a member of the domain the computer is attached to.
1 above could also be true if your domain is configured to run in a Windows 2000 Server compatibility mode. Coming back to the actual function call failing suggested by the Powershell script I gave you, the error happens because of a restriction on using the Kerberos authentication handshake, in particular the KERB_S4U_LOGON structure. This is related to the fact that the Windows Server 2003 domain controllers accept a new type of Kerberos request, where the service requests a ticket from the client to itself, presenting its own credentials instead of the client's. This extension is called Service-for-User-to-Self (S4U2Self) and it has to do with the "Protocol Transition" and "Constraint Delegation" Kerberos Extensions.
I won't be going into any more details here and I'm also not a domain administration / Active Directory Services expert. What we've documented on our wiki concerning the credentials involved in installing and deploying the F5 Management Pack, all stays true and in most Active Directory and Windows 2003/2008 domain configurations should be all we need. Obviously, there is a local restriction/condition in your Active Directory / Domain environment that prohibits the Kerberos handshake for the particular account(s) involved.
Julian - flipa_29928Just an uodate on this issue for those still interested.
The workaround that we used was to temporarily add the SCOM Administrator account into the Domain Admins group just long enough to allow me to install the F5 Management Pack.
I was able to install the MP to the RMS server without issue and could see all the F5 folder objects in the Monitoring view after the install completed.
I then repeated the install on the Managament Server that will be designated to monitor the F5 devices.
The first attempt to install to the Management Server failed as I had not added the F5 Management Pack service account to the Local Admins group on the Management Server.
After this was done setup Setup seemed to go OK but then just before finishing an error message popped-up similar to the one that Nick and Julian have been dealing with in a separate thread relating to:
"The DataSource and ConditionDetection modules required for the F5 Monitoring Service to run could not be loaded by Operations Manager monitoring host. Check the Operations Manager Event Log for errors and manually start the F5 Monitoring Service once any issues have been resolved."
I clicked OK to get past this message and then manually enabled the F5 Monitoring Services in the Services Applet.
Within a short while an alert in the SCOM Console relating to the stopped status of the F5 Monitoring Service on the Management Server auto-resolved itself when it detected that the F5 service was now running.
Eventually the Event Logs of the Management Server returned to a clean-state with just regular Informational events being logged. I also confirmed that the SCOM Console installed locally on the Management Server was also showing the F5 folders in the Monitoring view.
My question now is how do I know if the F5 Monitoring Service on the Management Server that is to be the actual point of contact for the F5 devices is healthy and OK to try and perform a device discovery on it given the error message above that indicates an issue with loading Datasource and ConditionDetection modules?
Was this a transient error that I can safely ignore now that the F5 monitoring service is running?
I hope to attempt a device discovery via this Management Server soon and I guess that will be the real-test but I would be more comfortable doing so if I could be sure that the error seen during installation is no longer an issue still that might lead t other problems.
Kind Regards,
Michael - Hi Michael,
The error you were getting could have been an isolated condition which eventually has cleared up with the F5 Monitoring Service / SCOM MonitoringHost initialization. I’d just check if the F5 Monitoring Log and the Operations Manager event logs are clean of any re-occurring errors, and then just try and discover an F5 Device.
But if you’re still getting the Data Source and Condition Detection failures, let us know and we’ll proceed with a deeper troubleshooting.
Thank you for the detailed feedback!
Julian
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
