Patrick McCarty wrote: > > > Patrick McCarty wrote: > >> > >> Attached is a patch against HEAD that provides the 'P' option for > >> acctFlags. > > > > Can you please verify that this is the correct bit to set? Rember, MS > > defines them - so we should check. Ethereal should be able to show you. > > I 'borrowed' this bit from the Samba-TNG code, which used it there. > > I thought the ACB bits were just a bitmask, and used only internally to > samba. Do they ever get sent to the client?
Yes - the client reads and sends them as a bitmask. > >> I havent been able to test this yet, so use with care. > >> > >> Ideally, this would eventually set the "user cannot change password" > >> bit to the client, but as Andrew mentioned, this hasnt been fully > >> implemented, and I'm not clear as to where in the code that > >> functionality should even be. (I am working on it however.) > >> > >> I plan on attempting to implement the pwdCanChange as well, as I > >> believe I understand how that could be done. > > > > This patch is incorrect. The problem is that there are about 5 > > different ways you can change a password remotely. > > When I was playing with a much simpler patch which in the > _samr_chgpasswd_user function simply returned NT_STATUS_ACCESS_DENIED, > Windows XP at least from the change password dialog box would correctly > report all password changes with a "You dont have access" type error > message. > > Perhaps other clients send different RPCs? There should be no other RPCs, but there are another 3 ways to change your password via lanman.c > I just quickly wrote the modifications to store the P flag per user, > instead of just blanketly denying password changes to everyone. > > What other RPC call remotely changes passwords? What did I miss? > > > Basiclly, the code needs a general rewrite - at the very lest we need > > the BOOLs converted to NTSTATUS. > > > > We don't really have a single 'choke point'. We need to get one, and to > > do access control etc there. > > > > change_oem_password() is as close as we get, and thats called *after* > > the unix password sync stuff. Sniff around the functions that call > > that, and try to get the scope of the problem. > > I definately will. I'm still trying to get a feel for how a password > change flows through the code -- But I thought I had it. It is a complex beast. -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
