NetUserSetInfo в Windows Server 2008 R2
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
struct USER_INFO_1003
{
public string usri1003_password;
}
[DllImport("Netapi32.dll")]
private extern static int NetUserSetInfo([MarshalAs(UnmanagedType.LPWStr)] string servername, [MarshalAs(UnmanagedType.LPWStr)] string username, int level, ref USER_INFO_1003 buf, out int error);
public static bool ChangePassword(string userName, string newPassword)
{
int errorCode = 0;
string serverName = null;
USER_INFO_1003 amUser = new USER_INFO_1003();
amUser.usri1003_password = newPassword;
int res = NetUserSetInfo(serverName, userName, 1003, ref amUser, out errorCode);
return (res == 0);
}
Пользователь, запустившый этот код авторизирован (с NTLM) в качестве администратора Windows. Та же проблема с другими основными функциями ОС. В чем проблема?
Вообще помоему ответ скрыт в вопросе - нет прав. Администратора в DACL некто не запрещал - запрещать. Так что нужно изучить DACL объекта для начала вместе с токеном процесса.
Цитата: Phodopus
Хм.. NetUserSetInfo() - основная функция системы? Ну ладно... :)
Вообще помоему ответ скрыт в вопросе - нет прав. Администратора в DACL некто не запрещал - запрещать. Так что нужно изучить DACL объекта для начала вместе с токеном процесса.
Вообще помоему ответ скрыт в вопросе - нет прав. Администратора в DACL некто не запрещал - запрещать. Так что нужно изучить DACL объекта для начала вместе с токеном процесса.
Основная - ето в смысле что из net api.
Токен процесса принадлежыт админу. Запретов никаких нет. UAC не при чом.
Все это очень подозрительно. Если токен есть и разрешен в DACL, то возможно в 2008 появилась какая-то привелегия которую предварительно нужно поднять. Но это уже вопрос по internals системы. В MSDN ничего такого не сказано. Могу только предложить распечатывать DACL и токен и смотреть.