{"id":682,"date":"2016-12-15T18:18:55","date_gmt":"2016-12-15T23:18:55","guid":{"rendered":"http:\/\/lisa.rushworth.us\/?p=682"},"modified":"2017-10-10T15:58:51","modified_gmt":"2017-10-10T20:58:51","slug":"custom-password-filter-update","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=682","title":{"rendered":"Custom Password Filter Update (unable to log on after changing password with custom filter in place)"},"content":{"rendered":"

I had written and tested a custom Active Directory password filter – my test included verifying the password actually worked. The automated testing was to select a UID from a pool, select a test category (good password, re-used password, password from dictionary, password that doesn’t meet character requirements, password containing surname, password containing givenName), set the password on the user id. Record the result from the password set, then attempt to\u00a0use<\/em> that password and record the\u00a0result from the bind attempt. Each test category has an expected result,\u00a0and any operation where the password set or bind didn’t match the expected results were highlighted. I also included a high precision timer to record the time to complete the\u00a0password set operation (wanted to verify we weren’t adversely impacting the user experience). Published results, documented the installation and configuration of my password filter, and was done.<\/p>\n

Until the chap who was installing it in production rang me to say he couldn’t actually log in using the password he set on the account. Which was odd – I set one and then did an LDAP bind and verified the password. But he couldn’t use the same password to log into a workstation in the test domain. Huh?? I actually knew people who wanted *some* users to be able to log in anywhere and others to be restricted to LDAP-only logons (i.e. web portal stuff) and ended up using the\u00a0userWorkstations attribute to allow logon to DCs only.<\/p>\n

We opened a case with Microsoft and it turns out that their Password Filter Programming Considerations<\/a> didn’t actually mean “Erase all memory used to store passwords by calling the SecureZeroMemory<\/strong><\/a> function before freeing memory.” What they\u00a0meant<\/em> was “If you have created copies of the password anywhere within your code, make sure you erase memory used to store those copies by calling SecureZeroMemory …”<\/p>\n

Which makes SO much more sense … as the comments in the code I used as our base says, why wouldn’t MS handle\u00a0wiping the memory? Does it not get cleaned well if you\u00a0don’t<\/em> have a custom password filter?? Remarked out the call to SecureZeroMemory and you could use the password on NTLM authentications as well as kerberos!<\/p>\n

\/\/ MS documentation suggests doing this. I honestly don’t know why LSA
\n\/\/ doesn’t just do this for you after we return. But, I’ll do what the
\n\/\/ docs say…
\n\/\/ LJR – 2016-12-15 Per MS, they actually mean to wipe any COPIES you make
\n\/\/ SecureZeroMemory(Password->Buffer, Password->Length);<\/p>\n

 <\/p>\n

I’ve updated my version of the filter and opened an issue on the source GitHub project … but if anyone else is working a custom password filter, following MS’s published programming considerations, and finds themselves unable to\u00a0use<\/em> the password they set … see if you are zapping your copies of the password or the\u00a0PUNICODE_STRING that comes in.<\/p>\n","protected":false},"excerpt":{"rendered":"

I had written and tested a custom Active Directory password filter – my test included verifying the password actually worked. The automated testing was to select a UID from a pool, select a test category (good password, re-used password, password from dictionary, password that doesn’t meet character requirements, password containing surname, password containing givenName), set …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33,30],"tags":[68,367,366,45,365,75,69],"class_list":["post-682","post","type-post","status-publish","format-standard","hentry","category-coding","category-system-administration","tag-active-directory","tag-active-directory-password-filter","tag-ad-password-filter","tag-coding","tag-custom-password-filter","tag-passfilt-dll","tag-security"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=682"}],"version-history":[{"count":3,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/682\/revisions"}],"predecessor-version":[{"id":685,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/682\/revisions\/685"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}