More Bidirectional eDirectory Driver errors

More Bidirectional eDirectory Driver errors

I recently got to work with the new (in 4.02) Bidirectional eDirectory driver on a project. As I went through that process I managed to grab a couple of error traces that I thought would be helpful to people, at the very least, showing up in a Google search, when troubleshooting.

I have done these error message articles before and you can find more examples for Active Directory:



For JDBC:


SAP HR:


SOAP:



And there are more, buried in other articles, that are hard to call out.

I have written a fair bit about the Bidirectional eDirectory driver, having done a detailed driver policy walkthough in the series below, plus an error article:



In that last article, I explained a series of funny errors that came up during a deploy, and would like to add some new ones that I saw go by as the project progressed.

Once we were ready to go live, the first thing we did was try to sync an object and set the password. We saw a cute error, and it was nice and clear from both the engine trace side and the LDAP trace side.

It is worth remembering that the Bidirectional eDirectory driver is really just an LDAP driver that can interface with a changelog module for eDirectory. Much like there is a changelog module in SUN Directory Server and other products. Amusingly, the M-Vault ISODE LDAP server (which is called out as a supported product in the documentation) product does not have a changelog module per se but rather tracks changes in a container that is only available to a single special user. Which makes for fun issues.

We knew the engine policies were basically working from our testing, so we watched first in the LDAP trace on the target replica server in the remote tree, which is backwards from normal, but lets do it this way for fun.

DoSearch on connection 0xf528380
Search request:
base: "cn=geoffc,ou=IT,o=ACME"
scope:0 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=*)"
attribute: "GUID"
Sending search result entry "cn=geoffc,ou=IT,o=ACME" to connection 0xf528380
Sending operation result 0:"":"" to connection 0xf528380
DoModify on connection 0xf528380
modify: dn (cn=geoffc,ou=IT,o=ACME)
modifications:
replace: cn
DDCModifyEntry failed, err = no access (-672)
Sending operation result 50:"":"NDS error: no access (-672)" to connection 0xf528380
DoModify on connection 0xf528380
modify: dn (cn=geoffc,ou=IT,o=ACME)
Unable to change or set password, err = bad password (-222)
Sending operation result 53:"":"NDS error: bad password (-222)" to connection 0xf528380


We see a DoModify in LDAP trace, to replace the cn attribute, and then a DDCModify Entry failed 672 no access error. Oh right, there is no development system here, so we were experimenting in production, and thus the account we used, was specifically set to read only permissions. I highly recommend NOT doing testing this way, it is much better to build out a test environment (and maintain it over time! Keeping it maintained is of course the really hard part. Far too easy to make changes you need in Prod and forget to back port them to Dev).

Well that is an easy fix. Give the account permission to modify the entry with the attributes we needed.

It is worth noting that in general, you should not make the driver Admin equivalent. Far better to grant specific permissions to just what you need to modify in the driver. The example I like best came from a customer that had a driver that never would delete users, but in error, several hundred thousand delete events came through and because the driver did not have Delete permissions on the target users, the events just nulled out. This of course saved a LOT of pain. If your driver can only do what it is specifically allowed too, then it cannot exceed those events, even by accident. Conversely it is a pain to figure out the exact permissions and grant them all specifically, but it is worth doing it.

Just for completeness, lets see what it looks like in the engine trace:

[07/08/14 11:37:52.434]:eDir Driver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<modify class-name="inetOrgPerson" event-id="idv1#20140708153750#1#1:f7bf4b08-1c29-43d3-15b3-084bbff7291c" from-merge="true" qualified-src-dn="O=acme\OU=users\CN=geoffc-cis" src-dn="\ACME-IDV\acme\users\geoffc-cis" src-entry-id="92420">
<association>8019AC33A448E311911E0002A547C9A4</association>
<modify-attr attr-name="cn">
<add-value>
<value type="string">geoffc-cis@acme.edu</value>
</add-value>
</modify-attr>
<operation-data attempt-to-match="true" unmatched-src-dn="CN=geoffc-cis"/>
</modify>
<modify-password class-name="inetOrgPerson" event-id="pwd-subscribe" qualified-src-dn="O=acme\OU=users\CN=geoffc-cis" src-dn="\ACME-IDV\acme\users\geoffc-cis" src-entry-id="92420">
<association>8019AC33A448E311911E0002A547C9A4</association>
<password><!-- content suppressed --></password>
<operation-data>
<password-subscribe-status>
<association>8019AC33A448E311911E0002A547C9A4</association>
</password-subscribe-status>
</operation-data>
</modify-password>
</input>
</nds>
[07/08/14 11:37:52.440]:eDir Driver ST:Password synchronization command detected.
[07/08/14 11:37:52.440]:eDir Driver ST:Stripping operation data from input document
[07/08/14 11:37:52.445]:eDir Driver ST:eDir Driver: LDAP Modify: cn=geoffc,ou=IT,o=ACME LDAPModification: (operation=add,(LDAPAttribute: {type='cn', value='geoffc-cis@acme.edu'}))
[07/08/14 11:37:52.458]:eDir Driver ST:eDir Driver: LDAPInterface.doLDAPModify() Modify Error4: LDAPException: Insufficient Access Rights (50) Insufficient Access Rights
LDAPException: Server Message: NDS error: no access (-672)
LDAPException: Matched DN:
[07/08/14 11:37:52.458]:eDir Driver ST:eDir Driver: LDAP Modify: cn=geoffc,ou=IT,o=ACME LDAPModification: trace suppressed for modification to userpassword
[07/08/14 11:37:52.493]:eDir Driver ST:eDir Driver: LDAPInterface.doLDAPModify() Modify Error4: LDAPException: Unwilling To Perform (53) Unwilling To Perform
LDAPException: Server Message: NDS error: bad password (-222)
LDAPException: Matched DN:



So you can see why we had two different events in the engine trace. First we sent a modify of the attribute CN, and then a second event, is a <modify-password>. Those correspond to our two events we saw on the LDAP side.

Thus our first 672 error is trying to modify CN. The second 222 error is trying to write to the password. Interestingly enough the 672 maps nicely to LDAP 50, which is Insufficient Access Rights, but the bad password write attempt. maps a LDAP 53, Unwilling to perform to an eDir 222 (Probably really an NMAS 222 to be fair) error.

What is even nicer, is that you can see the <modify> event, translated into LDAP'esque speak as:
[07/08/14 11:37:52.445]:eDir Driver ST:eDir Driver: LDAP Modify: cn=geoffc,ou=IT,o=ACME  LDAPModification: (operation=add,(LDAPAttribute: {type='cn', value='geoffc-cis@acme.edu'}))


Which if you space it out a bit with some white space might look like:

LDAP Modify: cn=geoffc,ou=IT,o=ACME  
LDAPModification: (
operation=add,
(LDAPAttribute:
{type='cn',
value='geoffc-cis@acme.edu'}
)
)


Which looks a bit more like an LDIF command this way.

I should try and get the message from a big <add> or <modify> event to see how it looks, but that is for another day.

To be even more complete, the status event that is returned looks like:

[07/08/14 11:37:52.494]:eDir Driver ST:
<nds dtdversion="2.0" ndsversion="8.x">
<source>
<product build="20140422_0454" instance="eDir Driver" version="4.0.1.1">Identity Manager Bi-directional Driver for eDirectory</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="idv1#20140708153750#1#1:f7bf4b08-1c29-43d3-15b3-084bbff7291c" level="error">LDAPException: Insufficient Access Rights (50) Insufficient Access Rights
LDAPException: Server Message: NDS error: no access (-672)
LDAPException: Matched DN: <operation-data AccountTracking-AppAccountStatus="-" AccountTracking-CN="geoffc-cis@acme.edu" AccountTracking-IdvAccountStatus="-" AccountTracking-Operation="modify" AccountTracking-association="8019AC33A448E311911E0002A547C9A4" attempt-to-match="true" unmatched-src-dn="CN=geoffc-cis"/>
</status>
<status event-id="pwd-subscribe" level="error">LDAPException: Unwilling To Perform (53) Unwilling To Perform
LDAPException: Server Message: NDS error: bad password (-222)
LDAPException: Matched DN: <operation-data>
<password-subscribe-status>
<association>8019AC33A448E311911E0002A547C9A4</association>
</password-subscribe-status>
</operation-data>
</status>
</output>
</nds>


Once we realized what the error was, we fixed the permissions and it worked, setting the second CN value (they wanted two CN values, so you could do logins with either CN, sort of an odd model but it did work), and the password.

What was interesting was that after a successful event, there is what almost looks like a loopback of the password from the remote eDirectory which seems to indicate it detects the event, via changelog. But the good news is, it does not actually process it. Just seems to detect and note it. Unless, upon re-reading it, by that line in trace, it may be trying to say that the changelog event for the password change event is being reported back complete, so that the changelog can remove it from the queue and not reprocess it.

[07/08/14 12:06:24.850]:eDir Driver PT:eDir Driver: Received the reponse from the engine after processing...
[07/08/14 12:06:24.851]:eDir Driver PT:eDir Driver: Processed 1 event out of 1.ChangeNumber of last processed is 6646292
[07/08/14 12:06:24.851]:eDir Driver PT:eDir Driver: Sending the last successful ChangeNumber 6646292 to connected system.
[07/08/14 12:06:24.851]:eDir Driver PT:eDir Driver: Sending Response : [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 4] OCTET STRING: 6D9D93B0-96A6-46a0-7C87-B0939D6DA696, [2] SEQUENCE: { [UNIVERSAL 2] INTEGER: 6646292, [UNIVERSAL 2] INTEGER: 0 } }
[07/08/14 12:06:25.052]:eDir Driver PT:eDir Driver: EdirPublisher - No intermediate response from server... will re-check after 10 Seconds.


I had an amusing error in the driver design, and my specific test user ended getting many CN values added to it, because the match criteria, the workforceID equivalent, was the same of 5 other users, as it was on me. So we got some fun multiple matches that look pretty funny. This is not specific to the Bidirectional eDirectory driver but was still interesting to work through.

The Subscriber Match rule generated a query for an user (inetOrgPerson in LDAP schema, usually) in the O=ACME container, whose workforceId is 9998.

[07/08/14 15:09:58.113]:eDir Driver ST:        
<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 class-name="inetOrgPerson" dest-dn="O=ACME" event-id="0" scope="subtree">
<search-class class-name="inetOrgPerson"/>
<search-attr attr-name="workforceId">
<value type="string">9998</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>


However, turns out we found two matches, myself and bsmith.


[07/08/14 15:09:58.366]:eDir Driver ST:        
<nds dtdversion="2.0" ndsversion="8.x">
<source>
<product build="20140422_0454" instance="eDir Driver" version="4.0.1.1">Identity Manager Bi-directional Driver for eDirectory</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<instance class-name="User" event-id="0" src-dn="cn=bsmith,ou=CS,ou=IT,ou=Adm,o=ACME">
<association state="associated">006845B8EA05E411911E0002A547C9A4</association>
</instance>
<instance class-name="User" event-id="0" src-dn="cn=geoffc,ou=IT,o=ACME">
<association state="associated">8019AC33A448E311911E0002A547C9A4</association>
</instance>
<status event-id="0" level="success"/>
</output>
</nds>
[07/08/14 15:09:58.367]:eDir Driver ST: Match found: src-dn='cn=bsmith,ou=CS,ou=IT,ou=Adm,o=ACME' association='006845B8EA05E411911E0002A547C9A4'
[07/08/14 15:09:58.368]:eDir Driver ST: Match found: src-dn='cn=geoffc,ou=IT,o=ACME' association='8019AC33A448E311911E0002A547C9A4'
[07/08/14 15:09:58.368]:eDir Driver ST: Evaluating selection criteria for rule 'Test for multiple matches'.
[07/08/14 15:09:58.368]:eDir Driver ST: (if-dest-dn available) = FALSE.
[07/08/14 15:09:58.368]:eDir Driver ST: Rule rejected.
[07/08/14 15:09:58.369]:eDir Driver ST:Policy returned:
[07/08/14 15:09:58.369]:eDir Driver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add cached-time="20140708190958.038Z" class-name="User" event-id="idv1#20140708190958#99#1:a7f88957-294b-4d3f-f0a7-5789f8a74b29" qualified-src-dn="O=acme\OU=users\CN=geoffc-cis" src-dn="\ACME-IDV\acme\users\geoffc-cis" src-entry-id="92420" timestamp="0#0">
<association>8019AC33A448E311911E0002A547C9A4</association>
<association>006845B8EA05E411911E0002A547C9A4</association>
<add-attr attr-name="floor">
<value timestamp="1404839140#2" type="string">72dgeoffc-cis</value>
</add-attr>
<add-attr attr-name="nspmDistributionPassword"><!-- content suppressed -->
</add-attr>
<operation-data attempt-to-match="true" error.do-find-matching-object="cn=bsmith,ou=CS,ou=IT,ou=Adm,o=ACME, cn=geoffc,ou=IT,o=ACME" unmatched-src-dn="CN=geoffc-cis"/>
</add>
</input>
</nds>
[07/08/14 15:09:58.371]:eDir Driver ST:Processing returned document.
[07/08/14 15:09:58.371]:eDir Driver ST:Processing operation <status> for .
[07/08/14 15:09:58.371]:eDir Driver ST:
DirXML Log Event -------------------
Driver: \ACME-IDV\acme\idm\DriverSet\eDir Driver
Channel: Subscriber
Object: \ACME-IDV\acme\users\geoffc-cis
Status: Error
Message: Code(-9062) Multiple matches found by object matching policy: cn=bsmith,ou=CS,ou=IT,ou=Adm,o=ACME, cn=geoffc,ou=IT,o=ACME.
[07/08/14 15:09:58.390]:eDir Driver ST:End transaction.


There are a couple of things worth noting in how that proceeded.

First up, after the Match, you will notice the <add> node has two <association> nodes. One for each found association, which of course does not make sense. Like the Highlander, there can be only one.

Thus the final error, that Multiple Matches found, and the two matching DN's get listed in the trace. (I remember the bug that requested that it show it in the <status> node. It used to just say, Multiple Matches found, without listing the names directly. Which was sort of useless, so a nice enhancement).

The second thing is the Operation Data node:

<operation-data attempt-to-match="true" error.do-find-matching-object="cn=bsmith,ou=CS,ou=IT,ou=Adm,o=ACME, cn=geoffc,ou=IT,o=ACME" unmatched-src-dn="CN=geoffc-cis"/>


It turns out the local variable, error.do-find-matching-object has the two values in it, and if you test for it, it is available. But the operation property of the same name is available, and also shows the values, which is nice.

Now is that error local variable stored as a nodeset of values, or a comma separated string? A nodeset can be an XML nodeset, in which case, regular XPATH applies, just start with the context of $VariableName/myXPath/Statement/Here but in the case of a nodeset of values you can say $VariableName[1] or $VariableName[last()] to get a specific position or the last position.

Or you can loop over every value in it to get them one by one.

I thought an example of what a Pub channel event looks like would be useful, so you can see what it should look like:

[07/10/14 12:20:10.337]:eDir Driver PT:eDir Driver: getEventList : Received LDAPMessage : LDAPExtendedResponse(117714): [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 2] INTEGER: 117714, [APPLICATION 24] SEQUENCE: { [UNIVERSAL 10] ENUMERATED: 0, [UNIVERSAL 4] OCTET STRING: , [UNIVERSAL 4] OCTET STRING: , [UNIVERSAL 4] OCTET STRING: 2.16.840.1.113719.1.14.100.201, [UNIVERSAL 4] OCTET STRING: 0?^@^@^@?0??^B^C^Ly?^D??CN=geoffc,OU=IT,O=ACMEaZbYmodifyaZbYadd: SAaZbYSA: testingaZbYadd: objectClassaZbYobjectClass: UseraZbYadd: GUIDaZgBmsM6RI4xGRHgACpUfJpA==aZbY } }
[07/10/14 12:20:10.339]:eDir Driver PT:eDir Driver: getEventList : Decoded sequence : [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 2] INTEGER: 817638, [UNIVERSAL 4] OCTET STRING: CN=geoffc,OU=IT,O=ACMEaZbYmodifyaZbYadd: SAaZbYSA: testingaZbYadd: objectClassaZbYobjectClass: UseraZbYadd: GUIDaZbYGUID: gBmsM6RI4xGRHgACpUfJpA==aZbY } }
[07/10/14 12:20:10.341]:eDir Driver PT:eDir Driver: Received an event sequence from eDirectory.Number of events in the sequence = 1
[07/10/14 12:20:10.341]:eDir Driver PT:eDir Driver: Started processing event 1 of 1
[07/10/14 12:20:10.342]:eDir Driver PT:eDir Driver: Received an modify event from eDir server...
[07/10/14 12:20:10.343]:eDir Driver PT:eDir Driver: GUID = 8019AC33A448E311911E0002A547C9A4
[07/10/14 12:20:10.344]:eDir Driver PT:
<nds dtdversion="4.0">
<source>
<product build="20140422_0454" instance="eDir Driver" version="4.0.1.1">Identity Manager Bi-directional Driver for eDirectory</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<modify class-name="inetOrgPerson" src-dn="CN=geoffc,OU=IT,O=ACME">
<association>8019AC33A448E311911E0002A547C9A4</association>
<modify-attr attr-name="street">
<add-value>
<value>testing</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>


I think that the string "aZbY" is how it representing a carriage return, or some other kind of white space.

If you replace all the "aZbY" strings with a carriage return, it is easier to read.

[07/10/14 12:20:10.337]:eDir Driver PT:eDir Driver: getEventList : Received LDAPMessage : LDAPExtendedResponse(117714): [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 2] INTEGER: 117714, [APPLICATION 24] SEQUENCE: { [UNIVERSAL 10] ENUMERATED: 0, [UNIVERSAL 4] OCTET STRING: , [UNIVERSAL 4] OCTET STRING: , [UNIVERSAL 4] OCTET STRING: 2.16.840.1.113719.1.14.100.201, [UNIVERSAL 4] OCTET STRING: 0?^@^@^@?0??^B^C^Ly?^D??CN=geoffc,OU=IT,O=ACME
modify
add: SA
SA: testing
add: objectClass
objectClass: User
add: GUIDaZgBmsM6RI4xGRHgACpUfJpA==
} }
[07/10/14 12:20:10.339]:eDir Driver PT:eDir Driver: getEventList : Decoded sequence : [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 2] INTEGER: 817638, [UNIVERSAL 4] OCTET STRING: CN=geoffc,OU=IT,O=ACME
modify
add: SA
SA: testing
add: objectClass
objectClass: User
add: GUID
GUID: gBmsM6RI4xGRHgACpUfJpA==
} }


Yep, that reads much better. You can see how it comes out as a LDIF formatted LDAP event from the LDAP driver, which makes sense. I am not sure what the encoded string "0?^@^@^@?0??^B^C^Ly?^D??CN=geoffc,OU=IT,O=ACME" before the DN means. Something I am sure, but since it properly decodes, does not really matter.

You can see how that LDIF format maps to the XDS in the event that follows it.

In the natural course of a driver processing events you end up with query events, querying back to the eDirectory driver looks a little bit interesting. First you have the normal XDS query.

[07/10/14 12:20:10.427]:eDir Driver PT:
<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 class-name="inetOrgPerson" event-id="0" scope="entry">
<association>8019AC33A448E311911E0002A547C9A4</association>
<read-attr attr-name="street"/>
</query>
</input>
</nds>


The shim converts that to an LDAP query, for a guid (interestingly escaped) first to get the DN, then second to get the actual attribute requested.

[07/10/14 12:20:10.442]:eDir Driver PT:eDir Driver: Making the GUID Cache capcity as 10000.
[07/10/14 12:20:10.442]:eDir Driver PT:eDir Driver: LDAP Search
base=O=ACME
scope=2
filter=guid=\80\19\AC\33\A4\48\E3\11\91\1E02\A5\47\C9\A4
attrs=[dn]
attrsOnly=false
[07/10/14 12:20:10.442]:eDir Driver PT:eDir Driver: OpenLDAPConnection - Connect to the server
[07/10/14 12:20:10.444]:eDir Driver PT:eDir Driver: Opening SSL connection
[07/10/14 12:20:10.491]:eDir Driver PT:eDir Driver: Host name: rhel-edir.root.acme.edu
[07/10/14 12:20:10.491]:eDir Driver PT:eDir Driver: Port: 636
[07/10/14 12:20:10.491]:eDir Driver PT:eDir Driver: DN: cn=idm,ou=it,o=acme
[07/10/14 12:20:10.492]:eDir Driver PT:eDir Driver: Protocol version=3
[07/10/14 12:20:10.492]:eDir Driver PT:eDir Driver: SDK version=4.6
[07/10/14 12:20:10.497]:eDir Driver PT:eDir Driver: LDAP Search
base=cn=geoffc,ou=IT,o=ACME
scope=0
filter=(objectclass=*)
attrs=[street, objectclass]
attrsOnly=false
[07/10/14 12:20:10.499]:eDir Driver PT:eDir Driver: Query.queryOperation() result=dn: cn=geoffc,ou=IT,o=ACME
street: testing
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: Person
objectclass: Top
objectclass: ndsLoginProperties

[07/10/14 12:20:10.499]:eDir Driver PT:eDir Driver: LDAP Search
base=cn=geoffc,ou=IT,o=ACME
scope=0
filter=null
attrs=[GUID]
attrsOnly=false
[07/10/14 12:20:10.501]:eDir Driver PT:eDir Driver: Querying for the GUID : GUID is 8019AC33A448E311911E0002A547C9A4
[07/10/14 12:20:10.501]:eDir Driver PT:Publisher shim returned:
[07/10/14 12:20:10.501]:eDir Driver PT:
<nds dtdversion="2.0" ndsversion="8.x">
<source>
<product build="20140422_0454" instance="eDir Driver" version="4.0.1.1">Identity Manager Bi-directional Driver for eDirectory</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<instance class-name="inetOrgPerson" event-id="0" src-dn="cn=geoffc,ou=IT,o=ACME">
<association state="associated">8019AC33A448E311911E0002A547C9A4</association>
<attr attr-name="street">
<value type="string">testing</value>
</attr>
</instance>
<status event-id="0" level="success"/>
</output>
</nds>


Finally converts the LDAP output back to XDS. You can also see it open the connection, which I guess was closed either because it timed out, or was the first event after a driver startup. This is nice, since you can confirm the port and IP used, as well as SSL or not.

Hopefully this is helpful to folk out there. Let me know if you come across any interesting errors, I would like to see write ups of all errors people come across, since then Google can find them, and everyone benefits from the shared effort.

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2014-09-11 17:17
Updated by:
 
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.