If this would be better served in just [Samba] or perhaps [Samba-Technical] as opposed to the maintainers list, my apologies and I'll route all similar things there in the future.<br><br>Using the latest debian, I've noticed odd behavior after provisioning:<br>
<br>The local user is seemingly added to the AD instance; even after reverting changes to PAM, logging in as the user who was active during provisioning gives this:<br>"Failed to modify entry for user <localuser>"<br>
<br>Invoking sudo gives the following:<br>"no talloc stackframe at ../source3/lib/util.c:1493, leaking memory<br>Failed to modify account record CN=<localuser>,CN=Users,DC=fake,DC=test to set user attributes: 0000052D: Constraint violation - check_password_restrictions: the password is too short. It should be equal or longer than 7 characters!"<br>
<br>Using ldbdel to remove the user returns a success, but subsequent logins seem to re-add the user (no replication -- only 1 DC in these test cases) to the AD instance, and the errors crop up again.<br><br>The leaked memory code ultimately leads here (I believe):<br>
<br>TALLOC_CTX *_talloc_tos(const char *location)<br>{<br> struct talloc_stackframe *ts =<br> (struct talloc_stackframe *)SMB_THREAD_GET_TLS(global_ts);<br><br> if (ts == NULL || ts->talloc_stacksize == 0) {<br>
_talloc_stackframe(location);<br> ts = (struct talloc_stackframe *)SMB_THREAD_GET_TLS(global_ts);<br> DEBUG(0, ("no talloc stackframe at %s, leaking memory\n",<br> location));<br>
#ifdef DEVELOPER<br> smb_panic("No talloc stackframe");<br>#endif<br> }<br><br> return ts->talloc_stack[ts->talloc_stacksize-1];<br>}<br><br>Interestingly %s is null at this point because of a bad call to it? <br>
"name = get_myname(talloc_tos())" (the call at util.c:1493).<br><br>In the 4.0.6 source tarball, the local user provisioning the domain is not added to the domain. And I imagine that to be the source of the issue.<br>
<br clear="all"><div>Mike Ray<br></div>