Комментарии 18
а что, 1с в наше время, по прежнему хранит логины а не sid и уж тем более sid history?
Они и не переходили на Kerberos. Все также NTLM авторизация.
это не связанные вещи... в AD если удалить учетку и создать заново с тем же именем, это будет новый объект с новым SID. В 1с это будет тот же самый пользователь, так как в конфе хранится только логин, причем только в формате domain\login.
По 1с это не совсем так, пользователь будет выглядить как старый по виду логина, но это будет уже другой пользователь, права и доступы будут уже дефолтные(если его удалить в 1с).
Продемонстрируйте пожалуйста прозрачную авторизацию в NTLM используя только SID пользователя.
Поэтому-то существует атака на NTLM — «Pass the hash».
1С незачем задумываться о SID и пр. она просто вызывает функцию LsaLogonUser.
А еще 1С это решение для малого бизнеса где может не быть AD, и с NTLM можно провернуть авторизацию, просто сделав одинаковых юзеров с одинаковыми паролями на разных рабочих станциях.
вот вы его и продемонстрировали, одинаковые пользователи с одинаковыми паролями будут иметь SSO по NTLM, и SID там будет вообще фиолетов...
Зачем задумываться о SID? Равно за тем же, зачем оно в AD - логин может поменятся. Более того, 1с это довольно популярный бухгалтерский софт, а бухгалтера как правило женщины. Они выходят замуж, и меняют при этом фамилию... меняется логин. В AD при этом ничего не ломается, как при Kerberos, так и при NTLM... а еще есть sid history, в случае миграции учетки между доменами....
В NTLM нет никаких SID.
О чем спор?
Если переименовать учетку в AD и не переименовать в конфигураторе, человек не зайдет в 1С.
Низкоуровневые вещи sid history, kerberos tiket и пр. не должны учитываться прикладным софтом. Просто прикладной софт надо переписать. Но как код авторизации был в 1С:7.7, которая работала еще на Win95, так и существует в неизменном виде.
Для служб 1с и iis лучше использовать group service management account.
Мы так сделали.
wonderland.v8.1c.ru/blog/autentifikatsiya-linux-klienta-sredstvami-os-kerberos
У вас веб-сервер и сервер приложений на разных машинах расположены?
У нас не получается пройти аутентификацию, когда на отдельных серверах. При этом, веб-клиент под IE её проходит.
У нас на одной и той же виртуалке.
На такой схеме не проверял, так как ушли от нее.
А зачем вам на разных, или вы используете разделенную систему как единую точку входа?. Если да, то советую от этого уйти и использовать для этого haproxy. Есть момент когда много баз на одном iis и при одинаковых названиях методов hs /ws тогда они работают поочередно с базами.
Спасибо за статью. Можно немного пояснить:
1. цель haproxy, 1с нормально привязывается к отдельным доменам, получаем возможность идти на разные домены из коробки. или это ради избавиться от некрасивого пути после домена?
2. зачем нужны пляски вокруг ApplicationPoolIdentity, вроде бы и со стандартными настройками все работает
Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)