11.10.2013, 15:13 | #1 |
Участник
|
Добрый день!
Новому пользователю, при регистрации логина в системе, присваивается стандартный пароль (из серии от 1 до 8). Есть задача, чтобы пользователь сменил пароль на уникальный в течении 10 дней. Как это лучше сделать? Возможно есть и стандартные средства, но я что-то вспомнить ничего не могу. Давно с администрированием не работал. Используется: 1) Клиент NAV 2009 2) SQL Server 2008 3) Ядро от Nav 2.60 Спасибо. |
|
11.10.2013, 15:51 | #2 |
Участник
|
В свойствах логина для пользователя на SQL сервере можно задать использование политики паролей. Там же можно указать использование срока действия пароля, необходимость смены пароля при следующем входе.
|
|
11.10.2013, 17:22 | #3 |
Участник
|
Цитата:
В итоге, что бы сменить пароль, придется звонить администратору. |
|
11.10.2013, 18:40 | #4 |
NavAx
|
а разве через клиента Нава не получится сменить?
или в новых Навах не предусмотрено?
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
14.10.2013, 10:09 | #5 |
Участник
|
|
|
14.10.2013, 18:03 | #6 |
Участник
|
В кодюните, который отвечает за вход в систему, возможно сделать проверку, к примеру, если пароль был изменен после регистрации, то выводить диалоговое окно, либо просто сделажть меседж!
|
|
15.10.2013, 17:48 | #7 |
Участник
|
|
|
16.10.2013, 13:02 | #8 |
Участник
|
я бы посоветовал в первую же инструкцию по пользованию системой включить слова, что действия логируются и виновным в случае чего считается тот чей логин зафиксирован. Поэтому меняйте пароль при входе и никому не сообщайте.
как-то так. И главное под подпись об ознакомлении. и все. Сами будут спрашивать как сменить. Потому что, если пользовательо сменит и повесит скажем на мониоре - это тоже не выход |
|
16.10.2013, 13:43 | #9 |
NavAx
|
Можно пойти дурацким путем
Заводить всех юзеров с одинаковым паролем "12345", например Фиксировать дату создания карточки пользователя в Наве Ежедневно гонять по будильнику периодическое задание, которое будет пытаться подключиться к базе данных через какой-нибудь там АДО.Коннекшын с логином юзера и паролем "12345" Если получилось и карточка юзера старше 10 дней, то юзера отругать (выслать ему письмо, позвонить и наорать, оштрафовать, уволить, заблокировать карточку юзера в Наве и заставить писать объяснительную и т.п.)
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
21.10.2013, 11:26 | #10 |
Участник
|
Цитата:
Сообщение от jopagames3
Цитата:
А у меня тогда тоже дурацкий вопрос к КГению - "А вам зачем, собственно, это всё надо?" Возможно, я чего-то недопонимаю и на нашем заводе тоже необходимо в срочном порядке внедрять подобную практику. Какую конкретно КОММЕРЧЕСКУЮ выгоду преследует предприятие, обязывая нового (с минимальными правами) пользователя жонглировать паролями? Ответ "Это для безопасности системы!" мне, сами понимаете, известен. (и "Я не вникал. Задача пришла сверху!" тоже) Интересуют детали: Что, современные пользователи Navision уже не в состоянии самостоятельно следить за своими паролями? Зачем придумывать целый "механизм" (задача, исполнители, санкции), когда есть стандартная процедура смены пароля от MS? Почему нельзя попытаться разъяснить пользователю основы безопасности(устно или письменно), а нужно сразу переходить к хардкор-программированию? Нет. Мне правда любпытно. P.S. Вариант, который я описывал в первом сообщении, это требование, которое породил бизнес. Т.е. так хотелось бы видеть им. |
|
15.11.2013, 10:53 | #11 |
Гость
|
Реальная постановка - ниже. используем cu1.
политики MS SQL естественно отключены. по п3: вообще-то формочку для смены пароля можно открывать из кода, появились какие-то новые триггера в 2009.... но я не помню как они называются) 1. Есть таблица на уровне сервера (в msdb) и точно такие же таблицы на уровне каждой БД. Таблица, на данный момент, содержит: - имя юзера, - признак, что пароль требуется сменить, - дату последней смены пароля этим юзером. 1.1. Изначально неким скриптом надо добавить в эту табличку юзеров, с указанием последней даты изменения пароля (если мы хотим, чтобы их пароли менялись в разные дни - изначально рисуем тут разные даты). 1.2. При вводе нового пользователя (логин БД) обязательно добавляем его в эту глобальную таблицу. Это можно дописать в какой-то триггер (скрипт по раздаче прав, запускаемый админами), чтобы админам не делать это вручную. 1.3. Добавим в некую глобальную таблицу на сервере вне базы настройку "Периодичность изменения пароля (дни)" (Именно на сервере, т.к. логин/пароль у пользователя общие для всего сервера, а не разные для каждой базы). Вводим туда некое число, например, 60 дней. Это надо сделать на каждом сервере, на котором существуют рабочие логины БД, т.е. все, кроме ВЦ. 2. При входе пользователя БД в систему (для пользователей win этих проверок быть не должно): 2.1. Данные из глобальной таблички по нему подтягиваются в локальную табличку БД. Если такого пользователя нет в глобальной таблице, то в базу его не пускаем, выдаем сообщение: "Доступ в базу по данному логину настроен некорректно. Обратитесь к администраторам ЦО." 2.2. Проверяем по локальной табличке «последнее изменение пароля» + "кол-во дней указанное в настройке периодичности смены пароля" дает день равный или больший текущего серверного - то для данной строки/логина глоб.таблички проставляем галку в поле "признак, что пароль требуется сменить". !!!ВАЖНО: Как я понимаю, в данном случае это будет не серверное время, а время установленное на ПК пользователя! В этом минус данного решения по сравнению с предыдущим. 3. На уровне БД (при входе пользователя в систему) происходит проверка, которая дает ошибку, если текущий пользователь должен сменить пароль. С описанием того, где это можно сделать. Меню Инструменты -> Безопасность -> Пароль. Надо будет также сделать подробную инструкцию (разместить в РП) - как сменить пароль, т.к. сейчас у нас некоторые пользователи даже фирму открывать не умеют, недавно заявка была. Этим, видимо, мне надо заняться J 4. Пользователь меняет пароль. Триггер отлавливает событие и заносит данные о том, что пароль изменен в глобальную табличку (снимает там признак и меняет дату последнего изменения). 5. Пользователь снова входит, снова выполняется п. 2. Только на этот раз в этих данных нет признака того, что пароль должен быть сменен. 6. В локальной БД проверка проходит без ошибок и пользователь успешно входит в БД. |
|