http://www.notesnet.ru/library/docid/F24AC2
http://www.notesnet.ru/library/docid/089D2A
но админское решение предпочтительнее!

Imake, спасибо за ссылки, буду разбираться. Что касается предложенного админского решения, я его предлагал админу еще до размещения поста. Ответ прост - дизайн names.nsf трогать низзя (предыдущей программер умудрился случайно убить адресную книгу, еле восстановили, теперь трогать ее - табу). К тому же одни пользователи привыкли авторизоваться по лотусовому имени, другие по емэйл, а против топ-менеджеров переть трудно...

 

К тому же одни пользователи привыкли авторизоваться по лотусовому имени, другие по емэйл, а против топ-менеджеров переть трудно...

стесняюсь спросить, а что думают сертифицированные (ваши) админы про, например:
The number of ways that a user can authenticate against the Web server has a direct impact on security. The more name variations that are allowed, the more open the Web site is to a dictionary attack. For example, if last name is a valid user name, in a large company it would be fairly easy to find a "Smith" or an "Adams." A hacker could easily try to gain access to the site with any number of common last names.

Налицо попытка спихнуть на девелоперов базовые принципы безопасности, которыми лотус прикрывается в целом

предыдущей программер умудрился случайно убить адресную книгу

это вообще жесть, убить на работающем сервере её достаточно затруднительно
трогать, конечно, АК нежелательно, но... надо трезво оценивать ситуацию - наваяете примочку в аутентификацию - как бы больше отгребать потом не пришлось, если что-то пойдет не так...

 

этих юзеров можно поместить в отдельную NAB и её дизай менять, подключить через DA
здесь, один из участников описывал свои экзерцизы (с дублированием и "расщеплением" аутентификации), используя DA + AD (на месте АД м.б. любой ЛДАП, в данном случае)
решение было не изящным, но он его заимплементил и остался удовлетворен

 

юзеров можно поместить в отдельную NAB и её дизай менять, подключить через DA

кстати, норм вариант...

а вообще задача от боссов "Ужесточить/запретить кому-то доступ с такими-то параметрами" требует ответа "Нет проблем, но (!) теперь ВСЕ должны логин вводить ТОЛЬКО мыло(или фулнейм, или как решите)", в случае недовольства - ссылка на задачу...

 

это вообще жесть, убить на работающем сервере её достаточно затруднительно

Ну убил это так, образно, юзеры все потерлись.

этих юзеров можно поместить в отдельную NAB и её дизай менять, подключить через DA

Попробую предложить этот вариант

 

Попробую предложить этот вариант

а мне ещё интересен мой бредовый вариант с фолдером и ограничением доступа на него группе - сработает ли? жаль сейчас некак проверить, но под клиентом точно работает отлично, а вот под вэб - хз...

 

тема началась с почты по пути уже надумали, что надо и на другие базы распространить...
соответственно с почтой - кому надо - тому и зарубили - индивидуально, по списку
со служебной софтиной - хз, думаю это стотыщпятьсот раз сделали с момента выхода 5-ки, надо загуглить и всё будет..
но это некошерно - давать доступ всем, а потом некоторым его вырезать.... проще давать доступ не всем в смысле по хттп

в этом варианте я бы на каждую форму, которую нужно видеть через веб вставил бы на WebQueryOpen агентика,
который бы и делал проверку на принадлежность юзера к какой-то группе, ну и если не принадлежит то отваливался бы по ошибке или рисовал тег "нет доступа"

 

добавлю контекстную ремарку. как у меня сделано в магазе.

сначала регится юзвер в отдельной базе. там проверяем всякие поля, одинаковые емайлы, имена и прочее. можно проверять и ваши условия.
на мыло приходит текст с сылкой. по ссылке запускаем агент с id который переносит данные а DA, рефрешит names для автологина и пр.

и в плане спама удобно и условия можно понаставить.