В проектах Access (*.adp) подключение к базе MS-SQL настраивается в пункте меню "Файл"-"Подключение". При работе под WINE недоступна возможность использовать для подключения логин и пароль пользователя WINDOWS ("Use Windows NT Integrated Security").
Версия Access?
Office 2000
Боря, можешь прокомментировать? Это не авторизация через домен имеется в виду?
как раз наоборот. в mssql, как минимум, 2 варианта авторизации: доменными аккаунтами системными аккаунтами Windows в данном случае имеетс ввиду второй вариант. приминительно к вайну, особо без разницы, потому что понятия "аккаунт Windows" в вайне вроде нет. по паролю по крайней мере. по поводу доменной авторизации есть отдельная бага, но не у каждого есть домен
В настройках "Data Link Properties" ("Подключение") проекта Access (.adp) есть возможность выбора между "Use Windows NT Integrated Security" и "Use a specific user name and password". Сия проблема есть очень важная для меня, поскольку при внесении каких-либо изменени в исходный файл нашего основного проекта Access (.adp) настройка авторизации при подключении к MS-SQL через "Use Windows NT Integrated Security" позволяет копировать один наш исходный файл проекта Access (.adp) всем пользователям сразу, сохраняя при этом уникальность их аккаунтов при подключении к MS-SQL.
Добрый день. Скажите, есть ли какие-то планы по решению данной проблемы?
Добрый день. Скажите пожалуйста планируется ли решить данную проблему?
Женя, можешь прокомментировать что-нибудь по механизма работы аутентификации по windows-паролю?
Я взглянул сюда: http://www.realcoding.net/teach/access/Glava 20/Index10.htm повспоминал, как я ранее настраивал MSSQL2005, поспрашивал Ивана, Костю и Диму... Итого, мои предположения (пока я не поставлю себе где-нибудь, access и mssql, иначе чем предположениями это не назову) таковы. MSSQL умеет аутентифицировать своими средствами, а может использовать интегрированную аутентификацию Windows. Сама аутентификация Windows может быть как доменная (через Kerberos в ActiveDirectory), так и обычная (NTLM различных версий, обычно NTLMv2). Причём переключение между вариантами интегрированной аутентификации Windows может быть как прозрачной, так и заданной. Проблемы wine могут быть в том, чтобы уметь работать через тот же NTLMv2 или GSSAPI (если в домене)... в этом случае, кстати, и виндовый remote desktop client (если он ещё на чём не обломается) должен будет заработать через wine.
Хотелось бы еще раз поднять этот вопрос.
Хотелось бы еще раз поднять этот вопрос. Это действительно важно и срочно.
Добрый день. Скажите, реально ли получить хотя бы какой-то ответ или прогноз по данной задаче?
Думаю, что даже для повторения этой проблемы нужно получить сначала подготовленные Access и MS-SQL, что само по себе отдельная задача... Боюсь, что я не возмусь огласить вменяемый срок, по решению этого вопроса... Я думаю, что степень решённости вопроса аутентификации определяется их поддержкой. Я бы свёл задачу к более простой, но определяющей ту же поддержку. Например, запуск виндовой утилиты удалённого рабочего стола под wine, возможно более просто определит работоспособность механизмов аутентификации.
Стоит воспроизвести у нас ситуацию. Денис, Андрей, сможете сделать бутылку с проблемой?
Мы будем осваивать ситуацию, тестируя поддержку NTLM, согласно баге 654.
К сожалению, в ближайшие полгода мы вряд ли сможем наладить аутентификацию в MS SQL через тикеты Kerberos.
Спасибо. Пошел вешаться ...
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
