- Integrated Systems
- About Us
- Integrated Systems
- About Us
11-29-2012 06:14 AM
Virtual Connect LDAP Integration Issues
Susan was looking to help a customer with an issue:
Has anyone seen this before? I need to track down an answer for my customer on this inquiry:
I’ve got a weird issue going on I was hoping you can track down for me. I have my OA’s, and Virtual Connect domain both setup to use LDAP for authentication. I can authenticate to the OA and/or VC as either the local account, or a domain account via LDAP, it works great.
Here is my issue. For PCI requirements, I have to either change the local accounts passwords every 90 days, or disable the local account and use LDAP, we have gone the disable local accounts route, its what we do on all of our Management type systems, like ILO. When I disable use local accounts in Virtual Connect, it loses communications to the OA’s and basically throws errors and you can’t manage the VC Domain any longer. There is a section in VC where I am able to enter in the credentials for communication with the OA’s, same as was used in the original setup where I used the local accounts. If I try putting in a LDAP account, it fails, so it looks to me that you can use LDAP for authentication to logon to the VC, but you can’t use it for the VC to OA communications.
Can you ping the blade team on this? I know the ability to disable local accounts on VC just came out in a recent firmware update that I am on, 3.70 for the OA and VC currently is what I have installed. I also can reproduce this at will by just disabling/enabling local account access within the OA. Once I re-enable local accounts on the OA, the VC initiates a recovery and is fine.
Info from Dan:
This is correct and by design as far as I am aware of. The VC module creates an OA account and uses that for communications with the OA.
This account would be considered a “Service Account” for any auditor which is usually allowed just fine.
Plus the account password is created by VC and unknown to all humans. So there is very little risk of someone actually logging into the account.
And more from Mark:
VC Firmware has supported the ability to disable Local User Accounts for a pretty long time, not recent.
VC 3.70 added only the ability to select Primary Remote Authentication Method which is just a fail-safe.
That allows the customer to choose either LDAP, Radius, TACACS as a Primary, and if it is determined to be in failed state, re-enable Local User Accounts.
This provides for the scenario where the LDAP server may have changed IP Address, but since that is hard-coded in VC, it is a catch-22 because if the Local User Accounts are disabled, and the settings are not valid anymore for LDAP, you are locked out. This feature prevents you from being locked out because it allows the “auto” re-enable of the local user accounts.
Additionally, the VC doesn’t have a Local Account for the OA to use for communication, it is not necessary.
However, as Dan was saying VC does create a local account (hidden) on the OA for specific activities.
Disabling Local User Accounts on the OA has existed for a while as well.
If un-checking the box on the OA “Enable Local Users”, causes a VC-OA communication issue, that is not expected behavior.
There is not specific enough information to understand exactly what is being seen.
Where exactly does the errors occur when the box is un-checked on the OA? The statement “VC initiates a recovery and is fine” doesn’t tell me enough.