Проблема с идентификацией офлайнового клиента на сервере. Что делать?

[Sinya]

Цитата:

Сообщение от Сабитов Андрей

Что значит юзеры открывают компьютеры длинными почтовыми паролями ? Да и много с чем шастают туда-сюда, домой или еще куда это ваши слова. А до этого вы говорите что "юзерам сообща нужна только почта и сетевой принтер сообща, изредка что-то другое"...
а в домене проще управлять как политиками безопасности, централизованными обнавлениями и многое многое другое !
Раз CRM у вас не единственное "бедствие", разбиреться для начала с другими...
НЕ НУЖНО БОЯТЬСЯ ДОМЕННЫХ СЕТЕЙ!!!!!
Сколько раз сталкивался с тем, что против доменной архитектуры, те - кто ее совсем не знает и учиться не желает! Насчет exchange я с вами тоже не соглашусь!!! Возможно вам проще с администрированием МDaemon, но это не ознчает чт он лучше !
И вообще для корректной работы MS Dynamics CRM необходимо наличие контроллера домена, а также рабочий станции должны быть введены в домен!
P.S. Я реализовывал такую "штуковину" как у вас, прроблеммы ОСОБЫХ не было! ввел пароль и нормально !

Юзеры как раз не открывают компьютеры длинными паролями.
Длинные пароли в домене - посему как почту из вне ломали перебором. Так как кое-кто желает видеть кривой web сервис ексченжа в интеренете, чтобы заходить с телефона с web браузером с случайным IP, а в этом сервисе нельзя включить только одного-двух-трех пользователей, а остальным напрочь к нему доступ запретить по любому паролю, как в MD. Имена ящиков спамерам известны прекрасно, утилит для взлома почтовых сервисов перебором - полный интернет.
На своих машинах же пользователям проще входить с прописанным только на ней коротким паролем. Почтовый пароль вбит один раз в почтовый клиент. Больше, собственно, и не требуется.

Про почту - столько глюков, столько спама и такого быстрого падения почтового сервера, если его прицепить к интернету не через отдельную машину-шлюз в роли аппаратного фильтра с не микрософтовским фильтром на MD не наблюдал ни на одной версии. Перенос на другую машину с захромавшей - вообще нереальная вещь, тогда как в MD это механический перенос его папок и никакого реестра! Плюс суточный бэкап всех настроек в крохотных файлах меньше дискеты друг за другом! Система безопасности при работе с web оболочкой также на порядок выше - любой пользователь может быть отключен от доступа к web отдельно и многое другое. Ну и чего там лучшего?! Но это отклонение от темы.

Домен хорош в хорошем для него месте. Там где стоят стационарные машины. И на каждой сидит по несколько пользователей, приходящих в свое время и работающих и чище и организованнее поэтому. В такой структуре и порядка больше. Сам по проектному бюро знаю. Там домен нужен. Это да. Но тут он абсолютно никчему в полном виде с рабочими станциями! Только для каких-то микрософтовских сервисов, явно без него не живущих, если только.

Мне не нужно перелопачивать старую сеть, имеющую свои заморочки и со стороны навязанные прихоти. Требуется только понять, где в клиенте CRM офлайновом на стороне рабочей станции сидит та неопределенность, которая то позволяет ему установиться в рабочее состояние, то не позволяет на разных рабочих станциях. И как с ней бороться. Больше ничего не требуется и не нужно во благо паранойи власти.

[Sinya]

Неужели подобный с идентификацией глюк ни у кого нигде не вылезал? Что-то не верится!

А как заставить CRM нормально слать cookies, чтобы локальный IE мог запоминать пароль для нее?

[Aleck]

Цитата:

Сообщение от Sinya

На своих машинах же пользователям проще входить с прописанным только на ней коротким паролем. Почтовый пароль вбит один раз в почтовый клиент. Больше, собственно, и не требуется.

Мало ли что им проще, чтобы решить проблему с CRM рабочие станции должны быть в домене и точка =)
Хочется сильно упросить пользователям жизнь - есть технологии аутентификации без ввода пароля - USB ключи, сканеры отпечатков, распознавание по картинке с веб-камеры и пр.

Или выносите тех самых трех пользователей которым нужна почта извне на отдельный сервер...

[Sinya]

Ну, хорошо, допустим, что без полного домена клиент устанавливается неустойчиво. Хотя клиент при установке и не отказывается ставиться не в домене, иногда работает нормально и в описании ошибок не требует домена. Думаю, тут не так все однозначно и работающий ответ есть. Жаль что нет никакого толкового любопытного хакера тут, понявшего, что у клиента изнутри творится и где лежат критичные данные для идентификации. Жаль пока сам с отладчиками и дизасемблерами не дружу. Будем считать первый вопрос пока неразрешимым.

Ну, а на второй, не такой сложный, вопрос, как подправить CRM сервер, чтобы он позволял на стороне клиентского интернет эксплоера запоминать пароль пользователя, а не забывал его все время тут кто-нибудь знает ответ? Тут домен уже вроде как совсем ни при чем!