Highlighted
Knowledge Partner
Knowledge Partner
820 views

LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuilt

but only for two of the users. 500+ others just fine.

IDM Bundle Edition 4.02
- Vault running on OES 11.3, ADdriver on Windows 2008R2 (yes I know, old, but no down time permitted, just don't go there)
- the box with the ADdriver is also the CA for their MAD
- the certs for LDAP on both boxes look OK, though both clearly self singed. (checked using Keystore Explorer)
- I see no SSL errors anywhere I've looked.
- there are no pw policies on the MAD side, but there is on the eDir Universal Password side.
- I'm more of a GroupWise and OES guy, so my IDM skills are a tad weak.
- the local person started messing with the email expiry notification about the same time, so that could be a cause or complication as well. (Lothar, you have email on this front)
- I have yet to get a clear view of where those two users are making the actual password change, one of them being el presedentee who says no downtime/MaintWindow permitted for the 7x24 business.
- the Assocation spelling error is how it shows in the logs missing the i that should be there.

Not sure where next to look or which part of the volume of logs I need to focus on, so here is the core of the failures hoping for some guidance.



DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Assocation does not resolve to an object in the application
DirXML: [08/31/18 16:31:58.19]: Loader: Calling subscriptionShim->execute()
DirXML: [08/31/18 16:31:58.19]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.19]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<check-object-password event-id="user-agent-check-password">
<association>9a4417750e2828409e8e977b21c0137d</association>
<password><!-- content suppressed --></password>
</check-object-password>
</input>
</nds>
DirXML: [08/31/18 16:31:58.31]: ADDriver: CheckPwd
DirXML: [08/31/18 16:31:58.42]: Loader: subscriptionShim->execute() returned:
DirXML: [08/31/18 16:31:58.42]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.42]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" type="driver-general" event-id="user-agent-check-password">Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
</status>
</output>
</nds>
DirXML: [08/31/18 16:31:58.42]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
DirXML: [08/31/18 16:31:58.48]: Loader: Calling subscriptionShim->execute()
DirXML: [08/31/18 16:31:58.48]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.48]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<query event-id="0" scope="entry">
<association>9a4417750e2828409e8e977b21c0137d</association>
<read-attr/>
</query>
</input>
</nds>
DirXML: [08/31/18 16:31:58.48]: Loader: subscriptionShim->execute() returned:
DirXML: [08/31/18 16:31:58.48]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.48]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" event-id="0" type="driver-general">Assocation does not resolve to an object in the application</status>
</output>
</nds>
DirXML: [08/31/18 16:31:58.48]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Assocation does not resolve to an object in the application
___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
Labels (1)
0 Likes
6 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuilt

I think this is because your association is wrong on these users; look at
the very first line you posted:


> DirXML Log Event -------------------
> Driver = \Tree\Company\IDM Drivers\Active Directory
> Thread = Subscriber Channel
> Level = error
> Message = Assocation does not resolve to an object in the application



For most things in the world there are two possible reasons for an error
about "bad credentials"; one is that the password is wrong, but the other
we often skip over is that the username is wrong. In IDM's case, it
determines the user via an association, which is when the engine stores
the (in microsoft active directory's (MAD) case) GUID of the object, so
that no matter what you do to the object going forward (change, rename,
move) the object can be found via its GUID. If that association is wrong,
though, e.g. because you created the user, then the username is
effectively wrong, and an attempt to verify the password matches the
vault's password will fail; the vault thinks the password is 'a', and MAD
may also think the password is 'a', but the vault thinks the GUID ia
DEADBEEFGOESHERE and MAD's object's GUID is really BEEFDEADGOESHERE.

To fix this, clear the driver association in the vault and re-migrate the
user, or something, so that the association is recreated. You could also
try to fix the association to be what MAD has stored, but it's a pain to
get the byte ordering perfect, and usually requires getting into adsiedit
(as I recall) to see the thing if not getting it via LDAP.... bleh.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuil

ab;2487549 wrote:

To fix this, clear the driver association in the vault and re-migrate the
user, or something, so that the association is recreated. You could also
try to fix the association to be what MAD has stored, but it's a pain to
get the byte ordering perfect, and usually requires getting into adsiedit
(as I recall) to see the thing if not getting it via LDAP.... bleh.


Did he reassociate bit, and it showed a different connector Object ID after that one one user. made no difference on that front for the other
The associate error is gone since then, I must have grabbed a too early instance of that error. Now one user get 'success' before the 52e error and the other gets

Driver = \LT\Labstat\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Could not set password via platform call. Err=2221 (user not found)


I see that the MAD objectGUID as pulled with LDAPexplorer is not something that typeable, sigh and pity.

As per AlexB, we are trying to get the users to log in via an LDAP tool to each of the DCs to see how that goes. Fingers Xed on that happening shortly.

ab;2487549 wrote:

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

Web interface? what is that?
___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuilt

On 09/13/2018 09:54 PM, konecnya wrote:
>
> Did he reassociate bit, and it showed a different connector Object ID
> after that one one user. made no difference on that front for the other


What specifically did you do? Delete the association value for this
driver config entirely? Clean out the association value portion with the
GUID? Other?

> The associate error is gone since then, I must have grabbed a too early
> instance of that error. Now one user get 'success' before the 52e error
> and the other gets
>
> Driver = \LT\Labstat\IDM Drivers\Active Directory
> Thread = Subscriber Channel
> Level = error
> Message = Could not set password via platform call. Err=2221 (user
> not found)


Seeing the trace leading up to this would probably be useful. I can guess
at what is happening, but it seems like the same problem, namely that the
association is wrong, but this is all pretty unusual. If we take a step
back from this problem have there been any unusual activities in either
the eDirectory or microsoft active directory (MAD) areas in the past week
or two?

> I see that the MAD objectGUID as pulled with LDAPexplorer is not
> something that typeable, sigh and pity.


True, it is not something meant to be typed, but it can still be
represented via something that is typed, usually hexadecimal characters
like 9a4417750e2828409e8e977b21c0137d, and you can take the value you see
in LDAP, base64-decode it, and then convert it to hexadecimal via a couple
commands in Linux pretty easily. The hard part is making sure that the
bytes are represented in the correct order (Google for big vs. little
endian for some computer science reading material if not already familiar
with the topic generally), and since "matching" is a built in feature and
concept within IDM, it is usually easier just to delete the association
and let the objects match up again.

> Web interface? what is that?


The interface you are using to interact with the forums appears to be the
web interface.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuil

ab;2487583 wrote:

What specifically did you do? Delete the association value for this
driver config entirely? Clean out the association value portion with the
GUID? Other?

in iManager, modify the user object, under IDM tab selected and deleted the connected system (AD the only one on this system).
made a change elsewhere and it re-associated promptly.

ab;2487583 wrote:

Seeing the trace leading up to this would probably be useful. I can guess
at what is happening, but it seems like the same problem, namely that the
association is wrong, but this is all pretty unusual.

finding the most recent instance of 52e and getting everything around that time sound about right? here it is

DirXML: [09/12/18 12:19:36.26]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Object = \Tree\Company\Main_Office\Fin\kpower
Level = success
DirXML: [09/12/18 12:19:36.26]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Object = \Tree\Company\Main_Office\Fin\kpower
Level = success
DirXML: [09/12/18 13:55:27.82]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Loader
Level = error
Message = Error receiving response during command authentication
DirXML: [09/12/18 15:09:09.02]: Loader: Calling subscriptionShim->execute()
DirXML: [09/12/18 15:09:09.02]: Loader: XML Document:
DirXML: [09/12/18 15:09:09.02]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<check-object-password event-id="user-agent-check-password">
<association>991552877f80fc47be86316659247e04</association>
<password><!-- content suppressed --></password>
</check-object-password>
</input>
</nds>
DirXML: [09/12/18 15:09:09.13]: ADDriver: CheckPwd CN=Bill DeBoss,OU=company Users,DC=company,DC=local
DirXML: [09/12/18 15:09:09.28]: Loader: subscriptionShim->execute() returned:
DirXML: [09/12/18 15:09:09.28]: Loader: XML Document:
DirXML: [09/12/18 15:09:09.28]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" type="driver-general" event-id="user-agent-check-password">Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
</status>
</output>
</nds>
DirXML: [09/12/18 15:09:09.28]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
DirXML: [09/12/18 15:09:09.35]: Loader: Calling subscriptionShim->execute()
DirXML: [09/12/18 15:09:09.35]: Loader: XML Document:
DirXML: [09/12/18 15:09:09.35]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<query event-id="0" scope="entry">
<association>991552877f80fc47be86316659247e04</association>
<read-attr/>
</query>
</input>
</nds>
DirXML: [09/12/18 15:09:09.36]: ADDriver: query
base DN: CN=Bill DeBoss,OU=company Users,DC=company,DC=local,
filter: (objectClass=*),
return: (attribute values) objectClass, objectGUID,
DirXML: [09/12/18 15:09:09.36]: ADDriver: query
base DN: CN=Bill DeBoss,OU=company Users,DC=company,DC=local,
filter: (objectClass=*),
return: (attribute values) objectClass, objectGUID,
DirXML: [09/12/18 15:09:09.36]: ADDriver: ldap get next page ( 2147483647)
DirXML: [09/12/18 15:09:09.36]: ADDriver: ldap get next page ( 2147483647)
DirXML: [09/12/18 15:09:09.36]: Loader: subscriptionShim->execute() returned:
DirXML: [09/12/18 15:09:09.36]: Loader: XML Document:
DirXML: [09/12/18 15:09:09.36]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<instance src-dn="CN=Bill DeBoss,OU=company Users,DC=company,DC=local" class-name="user" event-id="0">
<association>991552877f80fc47be86316659247e04</association>
</instance>
<status level="success" event-id="0"/>
</output>
</nds>
DirXML: [09/12/18 15:09:09.36]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = success



ab;2487583 wrote:
If we take a step
back from this problem have there been any unusual activities in either
the eDirectory or microsoft active directory (MAD) areas in the past week
or two?

Two things
The Windows Server cert on the box with the AD Driver expired and the CA was past its age limit on creating new ones, so that CA got recreated along with the server certs that don't show any link back to the CA (JXplorer complains about this and refuses to connect securely). Not sure what else might have been done on that box as they troubleshot that issue, and that box is where the CA was and is.
They started down the path of attempting to implement the password notification that I didn't finish sorting out what they stumbled along on before the password sync things became the primary issue.

ab;2487583 wrote:


> I see that the MAD objectGUID as pulled with LDAPexplorer is not
> something that typeable, sigh and pity.


True, it is not something meant to be typed, but it can still be
represented via something that is typed, usually hexadecimal characters
like 9a4417750e2828409e8e977b21c0137d, and you can take the value you see
in LDAP, base64-decode it, and then convert it to hexadecimal via a couple
commands in Linux pretty easily. The hard part is making sure that the
bytes are represented in the correct order (Google for big vs. little
endian for some computer science reading material if not already familiar
with the topic generally), and since "matching" is a built in feature and
concept within IDM, it is usually easier just to delete the association
and let the objects match up again.


very familiar with those bits, the trick is that LDAP Explorer is seeing the objectGUID along the lines of ™R‡€�Y$~ that doesn't even show right here so picture time
JXplorer shows (non string data)
No nice 0-9, a-f hexadecimal characters to deal with.
on the eDir side I see the Connection Object ID in the form expected such as 991552877f80fc47be86316659247e04

ab;2487583 wrote:

The interface you are using to interact with the forums appears to be the
web interface.

the sarcasm tags didn't survive as I attempt to use other than the favored NNTP, sigh, still getting used to doing it this way for this thread since I'm not otherwise following this forum.
___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuilt


> Message = Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
> <client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
> <server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
> <server-err-ex win32-rc="-2146893044"/>
> </ldap-err>


data 52e means bad password. 525 means wrong DN.
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP_INVALID_CREDENTIALS since MAD's CA expired & rebuil

konecnya;2487548 wrote:
but only for two of the users. 500+ others just fine.

IDM Bundle Edition 4.02
- Vault running on OES 11.3, ADdriver on Windows 2008R2 (yes I know, old, but no down time permitted, just don't go there)
- the box with the ADdriver is also the CA for their MAD
- the certs for LDAP on both boxes look OK, though both clearly self singed. (checked using Keystore Explorer)
- I see no SSL errors anywhere I've looked.
- there are no pw policies on the MAD side, but there is on the eDir Universal Password side.
- I'm more of a GroupWise and OES guy, so my IDM skills are a tad weak.
- the local person started messing with the email expiry notification about the same time, so that could be a cause or complication as well. (Lothar, you have email on this front)
- I have yet to get a clear view of where those two users are making the actual password change, one of them being el presedentee who says no downtime/MaintWindow permitted for the 7x24 business.
- the Assocation spelling error is how it shows in the logs missing the i that should be there.

Not sure where next to look or which part of the volume of logs I need to focus on, so here is the core of the failures hoping for some guidance.



DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Assocation does not resolve to an object in the application
DirXML: [08/31/18 16:31:58.19]: Loader: Calling subscriptionShim->execute()
DirXML: [08/31/18 16:31:58.19]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.19]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<check-object-password event-id="user-agent-check-password">
<association>9a4417750e2828409e8e977b21c0137d</association>
<password><!-- content suppressed --></password>
</check-object-password>
</input>
</nds>
DirXML: [08/31/18 16:31:58.31]: ADDriver: CheckPwd
DirXML: [08/31/18 16:31:58.42]: Loader: subscriptionShim->execute() returned:
DirXML: [08/31/18 16:31:58.42]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.42]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" type="driver-general" event-id="user-agent-check-password">Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
</status>
</output>
</nds>
DirXML: [08/31/18 16:31:58.42]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Check password connection validation.<ldap-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">
<client-err ldap-rc="49" ldap-rc-name="LDAP_INVALID_CREDENTIALS">Invalid Credentials</client-err>
<server-err>8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1</server-err>
<server-err-ex win32-rc="-2146893044"/>
</ldap-err>
DirXML: [08/31/18 16:31:58.48]: Loader: Calling subscriptionShim->execute()
DirXML: [08/31/18 16:31:58.48]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.48]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<query event-id="0" scope="entry">
<association>9a4417750e2828409e8e977b21c0137d</association>
<read-attr/>
</query>
</input>
</nds>
DirXML: [08/31/18 16:31:58.48]: Loader: subscriptionShim->execute() returned:
DirXML: [08/31/18 16:31:58.48]: Loader: XML Document:
DirXML: [08/31/18 16:31:58.48]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.0" asn1id="" build="20120330_120000" instance="\Tree\Company\IDM Drivers\Active Directory">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" event-id="0" type="driver-general">Assocation does not resolve to an object in the application</status>
</output>
</nds>
DirXML: [08/31/18 16:31:58.48]:
DirXML Log Event -------------------
Driver = \Tree\Company\IDM Drivers\Active Directory
Thread = Subscriber Channel
Level = error
Message = Assocation does not resolve to an object in the application


I recall the "assocation" spelling being a bug, fixed quite a while ago. But, since you're running an ancient version, that's probably why you're seeing it. It doesn't hurt anything.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.