Answer inline...
On 24/03/2021 15:38, Benner, Craig wrote:
Thanks for replying. I actually don't know what you exactly mean by `what type
of AttributeType are you using for this
attribute`. So, I'll try to show some code and explain what my code is doing
outside of what i don't show... I have it OO designed out to be able to manage
our AD for multiple styles of users, so it is hard to show all at once.
Here is a snippet of our "Search" method
SearchRequest searchRequest = new SearchRequestImpl();
searchRequest.setBase(new Dn(searchBaseDn));
searchRequest.setFilter(filter);
searchRequest.setScope(SearchScope.SUBTREE);
searchRequest.addAttributes((String[]) attributes.toArray(new
String[0]));
searchRequest.addControl(pagedSearchControl);
cursor = new EntryCursorImpl(ldapConn.search(searchRequest));
while (cursor.next()) {
try {
Entry result = cursor.get();
if (offset == null || offset.equals(pagesLooped)) {
if (processRanges) {
processRangeAttributes(ldapConn, result, attributes,
searchBaseDn);
}
results.add(result);
sizeOfResult++;
}
} catch (CursorLdapReferralException clre) {
do {
// ignoring referrals
} while (clre.skipReferral());
}
}
attributes.toArray logs out like this ==> [accountExpires,
altSecurityIdentities, badPasswordTime, badPwdCount, cn, distinguishedName,
extensionAttribute2, mS-DS-ConsistencyGuid, msDS-KeyVersionNumber,
msDS-SupportedEncryptionTypes, objectClass, objectGuid, objectSid, primaryGroupId,
pwdLastSet, sAMAccountName, uid, userAccountControl, userPrincipalName,
whenChanged, whenCreated]
Once the search method is complete, it returns the "entry" -or collection of
entrys to a method that runs that entry through a conversion process
Below is my current mess of code while trying to figure out how to manipulate
the bytes coming back for ms-ds-consistencyguid
for (Attribute a : entry.getAttributes()) {
....
log.debug("Setting field [" + attributeName + "] with value [" +
a.get().getString() + "] and field type ["
+ f.getType() + "]");
.....
} else if (f.getType().equals(byte[].class)) {
byte[] theValue;
if (a.isHumanReadable()) {
Here lie dragons...
The HR flag is set based on the LDAP API knowledge of the attributeType
characteristics. Sadly, we can't account for all the existing
attributeType definitions, and we have based this flag on the existing
RFCs were attributes are defined.
Bottom line, the MS AT is unknown to the API, thus the HR defaults to true.
(At some point we have to decide if the value is a String or a byte[])
There is a way to trick the API and tell it that the attribute is in
fact binary, by adding the attribute name to the list of binary
attributes managed by the DefaultConfigurableBinaryAttributeDetector
instance (see
https://nightlies.apache.org/directory/api/2.0.1/apidocs/org/apache/directory/api/ldap/codec/api/DefaultConfigurableBinaryAttributeDetector.html).
So if you call
connection.getBinaryAttributeDetector().addBinaryAttribute(
"mS-DS-ConsistencyGuid" ) method, that should do the trick.
Yes, I know, it's a bit tricky, it's not exactly well documented, but at
least, it should do the job :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org
