Jim Willeke

Well, I just could not leave it alone. This is just from some searching, no word on the real hoto. The return value of msDS-ManagedPassword is a msaBlob of a lot of items. (sort of described here https://markgamache.blogspot.com/p/gmsa-magic.html) Looks like this guy got it to work but using signing and sealing in a .NET project. https://markgamache.blogspot.com/2016/12/any-sufficiently-advanced-active.html Good Luck. -jim Jim Willeke On Sun, Sep 26, 2021 at 3:56 PM Jim Willeke jwilleke@users.sourceforge.net...

I have but: I am not sure what the problem is and I do not know what the "B64 encoded password" would be. Would you even be able to bind with that? Unfortunately, I also have no test environment for this and have not done Java stuff in a while. -- -jim Jim Willeke On Sun, Sep 26, 2021 at 10:02 AM Martin Jacobsen martin-jacobsen@users.sourceforge.net wrote: Did you get a chance to look at the code yet Jim? I did an experiment the other day, setting the same password as the gMSA on a normal user, and...

You should post your code. In Microsoft Active Directory the default password attribute is unicodePwd and I this requires special encoding as shown in this example: https://github.com/jwilleke/Examples-JNDI/blob/master/src/com/willeke/samples/ldap/jndi/ADConnection.java See (updateUserPassword(String username, String password)) -- -jim Jim Willeke On Thu, Sep 23, 2021 at 5:40 AM Martin Jacobsen martin-jacobsen@users.sourceforge.net wrote: Thx for your reply Jim. I've tried going down this path, using...

Using the "gMSA DN and an empty password" will make a successful "Unauthenticated Bind". For Microsoft Active Directory in most cases the operation is not usable to perform most LDAP Operations. AFIK, Microsoft Active Directory does not distinguish between Unauthenticated and anonymous operations. By default, anonymous Lightweight Directory Access Protocol (LDAP) operations to Active Directory, other than rootDSE searches and binds, are not permitted in Microsoft Windows Server 2003 and later. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/anonymous-ldap-operations-active-directory-disabled...

Did you check if your "inmemory server" supports "1.2.840.113556.1.4.803 https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_BIT_AND"? (As far as I know, ONLY Microsoft Active Directory supports it) I assume you are looking to find if some group of user entries are "Administratively Disabled https://ldapwiki.com/wiki/Active%20Directory%20User%20Related%20Searches#section-Active+Directory+User+Related+Searches-AllAdministrativelyDisabledUsersIeACCOUNTDISABLE2" something like: (userAccountControl:1.2.840.113556.1.4.803:=2)...

Searching by (samAccountName=<samaccountname value="">) should not be an issue. Do it everyday.</samaccountname> However, "When the user is in a different domain" needs to be clarified. If the "different domain" is a sub-domain, then you can probably perform a search for the user against the global Catalog https://technet.microsoft.com/pt-pt/library/cc728188%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 . if the user is not in a subdomain LDAP will can not be used. -- -jim Jim Willeke On Mon, Sep...

I think we are missing something else. Your UnboudID code is using "SearchScope.SUB" and JNDI is using: "SearchControls.ONELEVEL_SCOPE" That could make a difference, but I doubt it. Are you sure your "searchOU/ouEX" exists in both LDAP implementations? -- -jim Jim Willeke On Wed, Jun 20, 2018 at 10:43 AM Aman T techy7@users.sourceforge.net wrote: Neil, Thanks for the reply. Here's an interesting find... when I tried to execute the same logic using JNDI using the same bind credentials, everything...

Yes, Microsoft Active Directory has a concept called Ambiguous Name Resolution (https://ldapwiki.com/wiki/Ambiguous%20Name%20Resolution)...