OV access from POSH script via AD service account

[Jonathan_Deitch]

Anyone know how to make this work?

We have our AD integration setup as Active Directory and users can access just fine.

But service accounts don't work at all, the login sits and spins and times out with "appliance not accessible"

e.g.

Connect-OVMgmt : The appliance at 'oneview@test.com' is not responding on the network.

Change the credentials to a standard user, it connects instantly

[ChrisLynch]

Please provide more details on:

1. What OneView version you are using.
2. How have you configured AD authentication in OneView?
3. The "Service Account" setting when configuring an AD authentication directory is only used for Smart Card access, not for general AD authentication.

[ChrisLynch]

BTW, we have a video walking admins through the various options, requirements and steps on how to configure Microsoft Active Directory authentication with HPE OneView here.

[Jonathan_Deitch]

It's version 8.1

Our AD authentication is working (setup as Active Directory)

Our problem is, when scripting via POSH in PowerShell, we can access OneView using an AD user account.

We cannot access OneView using an AD service account

(the "service account" option for AD access is immaterial to this issue)

[Jonathan_Deitch]

Note, that I've also tried to setup via LDAP, and that flat out fails.

Correct DN (e.g. DC=name,DC=org)
Fails whether or not CN or UID is selected
OU line 1 = "OU=Groups"
OU line 2 = "OU=Users"
(also tried these in reverse order)

Added the LDAP servers (in this case our DCs) on 636
Validation always fails when you click Add

These are the same servers that connect just fine when added as Active Directory instead of LDAP.
And yes, LDAP works - we have vcenters connecting to these on LDAP just fine.

[Jonathan_Deitch]

Been there done that, does not solve this problem.

I already HAVE active directory successfully configured.
The problem is a USER can connect to OV.
a SERVICE ACCOUNT cannot.

[NJK-Work1]

Are you talking about a "Managed" service account (gMSA)?

If you are talking about gMSA, I think that will only work for services and maybe scheduled tasks...but I dont think it can be assigned as an "authorized user" within OneView.  So I dont think there is any way for OneView to authenticate a gMSA.

If you are not talking about a gMSA - then I dont see any reason why a "service account" would not work.  Assuming its just a normal user account that has been given permissions within OneView to login and "do stuff".  I guess I need to know how you define "Service Account" at your company - it might be different from what I am used to callinga  "service account".

NK

[ChrisLynch]

We cannot access OneView using an AD service account

(the "service account" option for AD access is immaterial to this issue)

Got it.  So a general description of a user account used specifically for non-interactive use.  

I think you are confusing the two directory options.  You cannot use the OpenLDAP option to connect to an Active Directory DC.  OneView already uses Secure LDAP to authenticate to DC's (or GC's if you use 3269/TCP instead of 636/TCP).  In order to authenticate to an AD Domain Controller, you need to specify Active Directory as the directory type.

[Jonathan_Deitch]

It's a standard service account (not gMSA).

If I put both a regular user, and the service account, into the same AD group granted priviliges in OneView, the standard user can access OV and the serivce account cannot.

In fact, when the service account attempts to connect, the OV socket dies entirely.

The error given is not a rejected login (e.g. invalid credentials), it's a failure to connect to OV entirely.  
From Powershell this manifests as a "server not responding" message.  Specifically states server at address XX X failed to respond.
From GUI, you get a spinning circle, then a browser connection error (page timeout).

[ChrisLynch]

Is this service account in the Protected User's Group? If so, we don't support that as OneView uses Secure LDAP, not Kerberos. Is this service account a standard AD User type? Is the service account in the same Domain as your other user accounts you can authenticate with?

[Jonathan_Deitch]

It is not a protected user group; it's a standard user type.  Same domain.

Literally from root of AD, there's "Groups", "Users", and "Service Accounts", all three right there on the root node.
It's a very standard AD setup.

[ChrisLynch]

What is the username format you are using in both cases (please provide a specific example) ? Do know the account you provide is used to initiate a Secure LDAP bind to a domain controller.

Can you authenticate with any other "service" account? This is seemingly more and more to be environment specific. And at this point, I would suggest a support case and provide an appliance support dump so one of the debug log files can be examined further.

[Jonathan_Deitch]

username format is the exact same : username@domain  .... e.g. blah@test.com
we do not use any special characters in names, all alphanumeric on either side of @ (other than ".")

I can open a support case, is there a way to open one specifically for OneView?

We aren't using a service account to bind our AD connection, it was verified by user (mine, in fact) when joined.

This is specifically for a user connecting to an already setup/configured AD connection.
Normal user = login OK
Service Account user = connection fails/times out

[ChrisLynch]

Yes, you can open a support case for OneView if you have a current OneView Advanced support, or the 9x5 OneView Standard support.

I was simply explaining how OneView authenticate to a domain controller.

[Jonathan_Deitch]

Ok, how does that work for Synergy?

Support case filed under the Composer serial ?

[ChrisLynch]

Yes.

[Jonathan_Deitch]

Cool, will do, thanks

[Jonathan_Deitch]

FYI, for anyone else who runs into this, we found the underlying issue :

If you specify username without domain, OneView will prepend the domain name.

e.g. username internally becomes DOMAIN\username

When using Active Directory connectivity, OneView internally is actually using LDAP, and the domain name search fails.

To make it work correctly you need to provide crendentials as FQDN : username@domain