|
26.02.2007, 13:21 | #1 |
Участник
|
Следующий улучшайзер, который может появиться, это скрипт на T-SQL, который правит параметры пользователя admin автоматически...
Не согласен, что это "взлом". Для проведения такой операции нужен доступ к базе. Взлом, это несанкционированное получение доступа. Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях. По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/ На практике это означает, что надо держать 2 набора логинов. 1. для АОСа - с полными правами 2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав. Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права... В общем, тема благодатная. Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте? |
|
26.02.2007, 13:39 | #2 |
Участник
|
Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё. Никакой интеграции прав доступа реально нет. Впрочем, это и не декларируется. Но зачем указан идентификатор пользователя в AD вместо варианта пользователь/домен? Старый добрый способ, только на другой лад? По сути, ничего же не поменялось. Или я что-то не понимаю?
|
|
|
За это сообщение автора поблагодарили: mazzy (5). |
26.02.2007, 13:51 | #3 |
Участник
|
Цитата:
Интересное наблюдение... Надо подумать. |
|
26.02.2007, 15:36 | #4 |
Участник
|
Цитата:
Цитата:
Но зачем указан идентификатор пользователя в AD вместо варианта пользователь/домен? Старый добрый способ, только на другой лад? По сути, ничего же не поменялось. Или я что-то не понимаю?
|
|
26.02.2007, 15:53 | #5 |
Участник
|
Цитата:
Сообщение от gl00mie
Поэтому "вот так сразу", видимо, отказаться от UserInfo не получится.SID однозначно идентифицирует пользователя из определенного домена, а связка SAM Account Name (логин в терминах AD) и DNS/NETBIOS Domain Name - нет. Логин может быть изменен, при том что пользователь (т.е. объект в AD и его SID) останется тот же самый; домен может быть переименован, причем могут измениться как оба названия (DNS и NETBIOS) домена, так и отдельно одно из них, при этом SID'ы объектов в AD останутся прежними. Поэтому полагаться на пару логин+домен в плане идентификации пользователей Windows-доменов нельзя. В виндах привязка пользователей/групп к тем же доменным политикам, спискам контроля доступа (ACL) и т.п. всегда идет по SID.
Такое ощущение, что единственное изменение по доступу - замена проверки пользователя с комбинации пользователь/домен в 3.0 на SID в 4.0. Но явных преимуществ сего действа я не вижу. Зато проблем стало вагон: без AD нового пользователя не добавить, тестовую базу из боевой быстро не приготовишь, при тестировании под чужим именем не войдёшь. |
|
26.02.2007, 17:17 | #6 |
Участник
|
Цитата:
Цитата:
Такое ощущение, что единственное изменение по доступу - замена проверки пользователя с комбинации пользователь/домен в 3.0 на SID в 4.0.
Цитата:
Но явных преимуществ сего действа я не вижу.
Цитата:
Зато проблем стало вагон: без AD нового пользователя не добавить
Цитата:
тестовую базу из боевой быстро не приготовишь
Цитата:
при тестировании под чужим именем не войдёшь.
Последний раз редактировалось gl00mie; 26.02.2007 в 17:25. |
|
27.02.2007, 09:28 | #7 |
Модератор
|
Цитата:
Один из вариантов - пользоваться виртуальными машинами. С Уважением, Георгий |
|
27.02.2007, 09:50 | #8 |
Участник
|
George, См исходную тему.
В исходной теме Михаил говорит о доступе к базам клиентов. Базы клиентов не на виртуальной машине. Если создать виртуальную машину и перенести туда базу, то SID все равно будут другими. Виртуальная машина решит проблему только демобаз. И вряд ли решит другие проблемы. |
|
26.02.2007, 13:51 | #9 |
Участник
|
Цитата:
Сообщение от mazzy
Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях.
По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/ На практике это означает, что надо держать 2 набора логинов. 1. для АОСа - с полными правами 2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав. Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права... В общем, тема благодатная. Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте? |
|
26.02.2007, 15:52 | #10 |
Участник
|
Цитата:
Сообщение от mazzy
Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях. По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/
На практике это означает, что надо держать 2 набора логинов. 1. для АОСа - с полными правами 2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав. Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права... Цитата:
В общем, тема благодатная. Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?
|
|
27.02.2007, 09:44 | #11 |
Участник
|
А где я говорил, про ограничение прав администраторов?
Я говорил про ограничение прав к данным. Эта задача актуальна не для администраторов, а для консультантов-программистов. Должен ли консультант иметь возможность непосредственной правки UserInfo.SID? Через Аксапту - да, а через EM - нет. Также он не должен иметь возможность правки через ODBC, ADO и другое. Только через Аксапту. |
|
27.02.2007, 13:04 | #12 |
Участник
|
Цитата:
Цитата:
Я говорил про ограничение прав к данным. Эта задача актуальна не для администраторов, а для консультантов-программистов.
Цитата:
Должен ли консультант иметь возможность непосредственной правки UserInfo.SID?
Через Аксапту - да, а через EM - нет. Также он не должен иметь возможность правки через ODBC, ADO и другое. Только через Аксапту.
|
|
27.02.2007, 13:11 | #13 |
Участник
|
ага. виноват. администраторов зря перечислил.
согласен, тема стоит того, чтобы над ней подумать. |
|
|
|