Добрый день! Не знаю в какую ветку обратиться.
Есть программа, которая нормально работает.
Смысл: пользователь запускает ехе-шник, вводит свой логин-пароль. Если в таблице users в поле role у него стоит 1, то ему загружается админский интерфейс программы, если 0 - интерфейс простого пользователя. Далее описывать не буду. Пишу на VS08 C#. СУБД MS SQL SERVER '08.
На предприятии настроен контроллер домена, где хранятся учетки всех пользователей сети.

Собираюсь переделать программу, чтобы пользователи не вводили логин-пароль из БД. А чтобы после запуска программа определяла под какой учеткой залогинен юзер в винду. Смотрела в домене, входит ли пользователь в группу "Администраторы ABC" например. Если пользователь входит в эту группу, то ему загружается админский интерфейс, иначе - иначе.
Немного изучил эту тему в интернетах, есть кое-какие мысли в голове.

Кто работал с доменными учетками из своих приложений? У кого какие советы есть?
Пока например вопрос такой в голове встает:
Вот допустим есть две таблицы в БД. Users и Comments.
В таблице Комментс есть поле User_ID. Ну связываются таблицы по этому полю.
А как же будет работать таблица Комментс с доменными учетками? Ведь таблица Users тогда вроде как не нужна мне будет? Или же всё-таки ее придется вести? Чо-то я не вкуриваю.
Как связать таблицу Комментс? может например по SID учетки?

Расскажите, кто что знает. Спасибо.

Система должна быть готова к тому, что у юзера может измениться буквально всё - от display name до logon name, так что при поднятии комментариев из базы стоит каждый раз забирать актуальные пользовательские данные из AD через SID юзера.
Таблицу с юзерами может пригодиться в том случае, если при удалении юзера из AD комментарий не должен оказаться безымянным, если же достаточно будет в имени написать "пользователь удалён", и нигде больше от юзера ничего не требуется, то можно обойтись и SID'ом, он однозначно идентифицирует пользователя в домене. Если же всё же вести таблицу с юзерами для прицепления вспомогательных данных, то лучше использовать для них суррогатный ключ (int, guid), а не SID для повышения производительности, а на поле SID просто навесить уникальный констрейнт.
Ещё при проверки роли пользователя стоит учесть, что он может и не быть членом группы "Администраторы ABC", но при этом входить в группу, которая входит в группу, ....., которая входит в "Администраторы ABC", т.е. проверка членства должна быть рекурсивной.

  Ага, и создадите этим массу проблем не только себе, но и системным администраторам. mihryak в кратце описал что ждет вас при разработке и это только малая толика. Все что вам нужно, это правильно воспользоваться тройкой "AD->SQL->Приложение" На мой взгляд, лучше решение, это определить нужные роли в БД и использовать их для ваших нужд. Проще говоря, при  входе пользователя определять к какой роли он принадлежит, и в зависимости от этого грузить нужный интерфейс. Вы легко можете управлять ролями, а администраторы их администрированием. Все просто и до одури приятно

Вобщем, нужен RoleProvider: как вариант