Comments 48
Как-то давно сделал сборку миранды для жаббера, прямо из которой можно было подключаться по РДП, удаленному помощнику, VNC, Radmin, к чему угодно, по сути. Т.е. прямо в интерфейсе диалога общения с юзером (или в ростере) были кнопки для запуска приложений с нужными параметрами. Имя компа бралось из «ресурса». Есть даже статья в инете. Ссылку давать не буду, т.к. однозначно ляжет.
Цитата из статьи:
Цитата из статьи:
Возможности:
Подключение Radmin (+ просмотр отдельно ), UltraVNC, TightVNC, Remote Desktop, compmgmt.msc (оснастка «управление компьютером»), открытие локальных дисков в Uneal Commander. Нужный вам функционал легко добавляется по аналогии.
Мультидоменность. Указав заранее какие группы к какому домену принадлежат (см. ниже) вы можете подлючаться к удаленным компьютерам в другой подсети. При условии, конечно, что у вас соответствующим образом настроена маршрутизация и адекватно работает DNS.
Внешняя аутентификация. Миранда лишь автоматически генерирует строку вызова приложения. Аутентификация и авторизация происходит средствами самого приложения, что исключает несанкционированный доступ через админ-версию (этот пункт как бы сам собой разумеется ) Хотя вы можете включить логин/пароль в ключи командной строки некоторых приложений.
У нас чатик не используется, но о подобных решениях тоже слышал.
У меня целая чреда решений была, на данную тему:
1. Ручное. В ту пору использовались удаленные профили на ФСе и опытном путем было выяснено, что быстрее получается посмотреть в РДП ФСа активную сессию от пользователя, отметив для себя имя машины с которой он соединен, нежели объяснять пользователю где он может это посмотреть сам. чтобы сообщить мне. Минус такого подхода очевиден — он ручной, плюс — если пользователям разрешено работать под своим логином с разных машин — мы 100% идентифицируем на какой машине он работает в данный момент времени.
2. Запретили пользователям логиниться со всех подряд машин, соответственно у них появилось значение атрибута Login To — для «напоминания» себе с какой машины работает пользователь, стало достаточно просто подглядеть данный атрибут через оснастку. Минус понятен — при заведении учетки пользователя, либо переезде пользователя на другое рабочее место — надо ручками изменить ему данный атрибут.
3. Внедрили в работу SCCM — описания излишни, очень удобный сервис от МС. Минус — не подходит для использования в смешанных сетях.
Статью прочитал с огромным интересом, спасибо.
1. Ручное. В ту пору использовались удаленные профили на ФСе и опытном путем было выяснено, что быстрее получается посмотреть в РДП ФСа активную сессию от пользователя, отметив для себя имя машины с которой он соединен, нежели объяснять пользователю где он может это посмотреть сам. чтобы сообщить мне. Минус такого подхода очевиден — он ручной, плюс — если пользователям разрешено работать под своим логином с разных машин — мы 100% идентифицируем на какой машине он работает в данный момент времени.
2. Запретили пользователям логиниться со всех подряд машин, соответственно у них появилось значение атрибута Login To — для «напоминания» себе с какой машины работает пользователь, стало достаточно просто подглядеть данный атрибут через оснастку. Минус понятен — при заведении учетки пользователя, либо переезде пользователя на другое рабочее место — надо ручками изменить ему данный атрибут.
3. Внедрили в работу SCCM — описания излишни, очень удобный сервис от МС. Минус — не подходит для использования в смешанных сетях.
Статью прочитал с огромным интересом, спасибо.
Спасибо за статью.
Сразу рекомендация: если собираетесь искать по значению созданного атрибута — поставьте в его свойствах флаг «Индексировать атрибут» (на вашем скриншоте он не стоит)
Было очень интересно прочитать про альтернативное решение.
Я, в свою очередь, когда столкнулся с необходимостью поиска компьютера пользователя — написал на C# службу, подписывающуюся на события входа в систему на всех контроллерах и сохраняющую эту информацию в SQL БД.
Сразу рекомендация: если собираетесь искать по значению созданного атрибута — поставьте в его свойствах флаг «Индексировать атрибут» (на вашем скриншоте он не стоит)
Было очень интересно прочитать про альтернативное решение.
Я, в свою очередь, когда столкнулся с необходимостью поиска компьютера пользователя — написал на C# службу, подписывающуюся на события входа в систему на всех контроллерах и сохраняющую эту информацию в SQL БД.
Да, на скриншоте нет. В рабочей конфигурации есть.
Регистрация событий входа тоже интересно. Хотя, мне кажется, имеет свои существенные недостатки.
Регистрация событий входа тоже интересно. Хотя, мне кажется, имеет свои существенные недостатки.
Ну — у меня задача стояла шире — нужно было получить физическое расположение пользователя — поэтому в той же БД ведётся журнал размещения сетевого оборудования и кроссовки кабельных систем. По данным из cisco + события входа + журнал кроссировки определяется из какого помещения, через какой порт оборудования пользователь осуществлял вход в систему в последний раз.
А не могли бы вы поделиться своим примером на C#? Я начинающий программист и как раз решаю подобную задачу.
Изобретатели велосипедов снова изобрели велосипед без колес! :)
Что может быть приятнее чем 8000 запросов на обновление атрибута каждое утро?
Сможете сделать скрипт, который выберет такую информацию из журнала безопасности контроллеров домена с временем входа и выхода?
Что может быть приятнее чем 8000 запросов на обновление атрибута каждое утро?
Сможете сделать скрипт, который выберет такую информацию из журнала безопасности контроллеров домена с временем входа и выхода?
или вообще пусть в базу записывает, зачем AD использовать для хранения информации :)
А что, 8000 это много?
База AD довольно эффективна. А выборка из журнала безопасности это минутное дело? К тому же там свои грабли.
Если уж будет 8000 каждое утро, я лучше, как предложили ниже, действительно буду писать в отдельную БД.
База AD довольно эффективна. А выборка из журнала безопасности это минутное дело? К тому же там свои грабли.
Если уж будет 8000 каждое утро, я лучше, как предложили ниже, действительно буду писать в отдельную БД.
Это _не_ нормально.
Да, у велосипеда есть много вариантов.
Я вам расскажу про довольно таки старинный велосипед, изобретенный еще в каменном веке, эпохе NT4.
logon.cmd
echo %date%-%time% %username%-%computername% >>\\SERVER01\Share\logonstat.txt
Примерно так.
Если бы был нормальный способ сопоставления пользователя и ПК — Microsoft давно бы это уже сделала, в промежутке между покупкой Skype и Nokia.
Способ записи имени ПК в AD при входе состоит только из недостатков.
— Что если компьютера два? Вы уже сами выше рассмотрели что это доставит интересных эффектов.
— Что если я не входил в сеть перед разблокировкой экрана, а подключил ноутбук к сети после входа в ОС?
— А когда я вышел из машины? А если она перед этим просто заснула?
При хорошей фантазии, можно написать целую страницу, когда и почему это не работает как ожидается.
В общем задача эта _нормально_ и универсально не решается, и всегда придется мириться с каким-то компромиссом. Не надежно.
Даже вариант с унылым bginfo.exe кажется не таким унылым (если сотрудник умеет читать).
Да, у велосипеда есть много вариантов.
Я вам расскажу про довольно таки старинный велосипед, изобретенный еще в каменном веке, эпохе NT4.
logon.cmd
echo %date%-%time% %username%-%computername% >>\\SERVER01\Share\logonstat.txt
Примерно так.
Если бы был нормальный способ сопоставления пользователя и ПК — Microsoft давно бы это уже сделала, в промежутке между покупкой Skype и Nokia.
Способ записи имени ПК в AD при входе состоит только из недостатков.
— Что если компьютера два? Вы уже сами выше рассмотрели что это доставит интересных эффектов.
— Что если я не входил в сеть перед разблокировкой экрана, а подключил ноутбук к сети после входа в ОС?
— А когда я вышел из машины? А если она перед этим просто заснула?
При хорошей фантазии, можно написать целую страницу, когда и почему это не работает как ожидается.
В общем задача эта _нормально_ и универсально не решается, и всегда придется мириться с каким-то компромиссом. Не надежно.
Даже вариант с унылым bginfo.exe кажется не таким унылым (если сотрудник умеет читать).
Я соглашусь, что для каждой компании есть свои методы решения. Определенно, в компании со 100 тысячами сотрудников, мой способ неприемлем и надо искать другие методы. Но в компаниях среднего размера, с количеством сотрудников до 1000 я бы не считал этот метод определенно плохим.
По поводу ваших вопросов, не сказал бы что это большие проблемы.
Что есть компьютеров два? Разблокировка экрана. Кто последний тот и комп. Не думаю, что найдется сотрудник, который специально разблокирует компьютер и метнется к предыдущему, пока он не заблокировался.
Что если не входили в сеть? Если в компании бы это встречалось, я бы понял проблему, в нашей такая ситуация исключена. Хотя решение этой ситуации у меня есть в голове, только оно не требуется.
Если вышел из машины? Ну выходи, вряд ли пользователь будет звонить с проблемой с выключенным компьютером. Я намеренно не стал делать механизм очищения атрибута при выходе из системы т.к. не смог объяснить для себя для чего это нужно. Ну будет устаревшая информация, в чем проблема?
Я бы, кстати, с удовольствием послушал какие бывают еще ситуации. Можно теоретически предположить тучу уникальных случаев, вплоть до того, что на компьютере отказываются запускаться VB скрипты, но подобные вещи я бы отнес к исключительным, которые можно понять и простить. А вот смоделировать реальные ситуации было бы интересно. Я попытался в голове прогнать все что может случиться и отнес либо к незначительным проблемам, либо решил их, например с помощью разблокировки.
С компромиссом придется мириться, согласен, но в ИТ вообще все невозможно считать надежным на 100%. И средства, затраченные на абсолютную надежность могут быть неоправданно большими. Я лучше потерплю 5% ошибочных определений компьютера в моем случае, чем вообще буду без этой системы.
По поводу ваших вопросов, не сказал бы что это большие проблемы.
Что есть компьютеров два? Разблокировка экрана. Кто последний тот и комп. Не думаю, что найдется сотрудник, который специально разблокирует компьютер и метнется к предыдущему, пока он не заблокировался.
Что если не входили в сеть? Если в компании бы это встречалось, я бы понял проблему, в нашей такая ситуация исключена. Хотя решение этой ситуации у меня есть в голове, только оно не требуется.
Если вышел из машины? Ну выходи, вряд ли пользователь будет звонить с проблемой с выключенным компьютером. Я намеренно не стал делать механизм очищения атрибута при выходе из системы т.к. не смог объяснить для себя для чего это нужно. Ну будет устаревшая информация, в чем проблема?
Я бы, кстати, с удовольствием послушал какие бывают еще ситуации. Можно теоретически предположить тучу уникальных случаев, вплоть до того, что на компьютере отказываются запускаться VB скрипты, но подобные вещи я бы отнес к исключительным, которые можно понять и простить. А вот смоделировать реальные ситуации было бы интересно. Я попытался в голове прогнать все что может случиться и отнес либо к незначительным проблемам, либо решил их, например с помощью разблокировки.
С компромиссом придется мириться, согласен, но в ИТ вообще все невозможно считать надежным на 100%. И средства, затраченные на абсолютную надежность могут быть неоправданно большими. Я лучше потерплю 5% ошибочных определений компьютера в моем случае, чем вообще буду без этой системы.
К сожалению (или к счастью) некоторые кампании из 1000 сотрудников имеют тенденцию вырастать до 100000 сотрудников, а «велосипеды» остаются старые…
Согласитесь, что не совсем рационально в компании из 10 человек внедрять корпоративные решения только потому что у компании есть амбиции?
сотрудников до 1000
в компании из 10 человек
Вы уж определитесь с размером компании ;)
И никто не призывает внедрять «корпоративные» решения (например использовать в качестве БД Oracle) — речь идёт о применении концептуально «правильных» решений (например если у Вас маленькая компания — возьмите sqlite — всегда сможете заменить на oracle с минимумом доработок — логика работы не изменится.)
Я не про оракл, а про то что в какой-то момент ексель, например, удобнее специализированной системы. До определенного момента. Также и здесь, я считаю, что если компания еще не реально большая, можно довольствоваться и такими методами, и вряд ли стоит их не использовать только потому что эта компания может войти в 1%, которых разрастется до стотысячных размеров.
Очень круто, спасибо :)
А зачем было создавать отдельный атрибут в схеме? Есть готовое поле userWorkstations.
К тому же, с помощью групповых политик можно разрешить пользователям логиниться только на своих компьютерах.
К тому же, с помощью групповых политик можно разрешить пользователям логиниться только на своих компьютерах.
Вообще-то userWorkstations для другого используется. У меня не было цели ограничивать никому доступ, была цель только попытка определить текущий компьютер пользователя.
Если не применять политику, Вы и не ограничиваете, просто есть такая возможность, а так можно хранить значение текущего компьютера в существующем поле.
Ну… вообще-то userWorkstations как-раз для того и сделано. В этом поле прописываются компьютеры, которым разрешен вход пользователю.
Новый атрибут я для того и сделал, что бы не напарываться на случаи, когда это делать бы не стоило. Потом исправлять свои ошибки куда сложнее, чем сразу попытаться предусмотреть их.
Новый атрибут я для того и сделал, что бы не напарываться на случаи, когда это делать бы не стоило. Потом исправлять свои ошибки куда сложнее, чем сразу попытаться предусмотреть их.
В схеме 2012 появился primary computer, который отлично подходит для описанной цели.
Ни разу не подходит.
ms-DS-Primary-Computer — атрибут ссылка. Он должен содержать DN компьютера.
msdn.microsoft.com/en-us/library/windows/desktop/hh446627%28v=vs.85%29.aspx
Тому, кто запишет в него имя ПК или ip «придёт счастье», в виде неработающего нового функционала
ms-DS-Primary-Computer — атрибут ссылка. Он должен содержать DN компьютера.
msdn.microsoft.com/en-us/library/windows/desktop/hh446627%28v=vs.85%29.aspx
Тому, кто запишет в него имя ПК или ip «придёт счастье», в виде неработающего нового функционала
Я бы Вам крайне не рекомендовал использовать не по назначению атрибуты. Потом такой сюрприз получается…
Наверное, у всех системных администраторов была проблема определения имени компьютера пользователя.Да, была, а потом мы во время инвентаризации составили план офисных помещений, с указанием какой компьютер в каком кабинете стоит, какое имеет имя, кто за ним сидит. И далее, найдя на плане, где сидит сотрудник, можно узнать имя компьютера.
Прекрасно, вот только такой план имеет тенденцию быстро устаревать :(
Это, конечно, хорошо, когда этот план есть. Но в работе все что может быть автоматизировано, должно быть автоматизировано. В какой-то момент кому-то будет лень внести изменение. А потом изменение не будет внесено потому, что план будет казаться все равно не актуальным. Да и есть в компании 500 рабочих мест, стоит предполагать что ручная запись работать не будет. А если рабочие места еще и географически распределены?
Подумайте над следующим:
У Вас в скрипте подключения к компьютеру для удалённого управления явно заданы учетные данные.
Что запустить консоль ADUC у себя на компьютере не надо быть администратором домена.
Т.е. у Вас на предприятии любой пользователь домена, запустивший у себя ADUC, получит возможность удалённого управления другими компьютерами!?
У Вас в скрипте подключения к компьютеру для удалённого управления явно заданы учетные данные.
Что запустить консоль ADUC у себя на компьютере не надо быть администратором домена.
Т.е. у Вас на предприятии любой пользователь домена, запустивший у себя ADUC, получит возможность удалённого управления другими компьютерами!?
Про скрипт я также написал, что учетные данные можно не вписывать. Похоже я не написал об этом в статье, но точно собирался, о том что скрипт стоит держать в доступном только ИТ отделу месте. В любом случае это не копирка нашего использования, также это не четкая инструкция к выполнению и корректируется каждым администратором в угоду своих требований к безопасности. Уверен, что по политике безопасности даже имя компьютера в атрибутах пользователя будет являться брешью и будет требоваться запрет на чтение. Так что мое дело привести пример, на основе которого можно сделать что-то свое и, скорее всего, лучше.
Согласен bginfo Решает проблему.
В телефоне также забил Фамилия и имя ПК.
Плюс наклеил наклейки на мониторы. (после «инвентаризации» некоторые стали говорить номер системника или монитора)
Главное не давать лишних букв.
Ибо народ порой будет их опускать. Лучше цифры. Только цифры. Хотя префикс обычно вводят для облегчения поиска на деле он только затрудняет поиск.
Кстати в комментариях к пк указываю фамилию и телефон в DameWare это очень помогает можно сортировку сделать по фамилии и телефон сразу видно.
В телефоне также забил Фамилия и имя ПК.
Плюс наклеил наклейки на мониторы. (после «инвентаризации» некоторые стали говорить номер системника или монитора)
Главное не давать лишних букв.
Ибо народ порой будет их опускать. Лучше цифры. Только цифры. Хотя префикс обычно вводят для облегчения поиска на деле он только затрудняет поиск.
Кстати в комментариях к пк указываю фамилию и телефон в DameWare это очень помогает можно сортировку сделать по фамилии и телефон сразу видно.
У нас как-то тоже остро стоял вопрос определения имени компьютера пользователя. Поначалу старались имя компьютера делать таким же, как и логин пользователя, но бывало так, что либо у пользователя логин какой-то заковырчатый и набирать его было проблематично, либо бывало, что сотрудники за одним и тем же компьютером менялись.
В итоге мы не стали привязывать имена компьютеров к логинам, а стали привязывать к номеру телефона, т.е. если пользователь звонит с телефона 1234, то имя компьютера w1234.
Да, это не отменяет путаницы, когда пользователь один, компьютеров два, телефонных аппаратов два, а номер один, но такие пользователи уже обучены называть правильное или возможное имя компьютера.
В итоге мы не стали привязывать имена компьютеров к логинам, а стали привязывать к номеру телефона, т.е. если пользователь звонит с телефона 1234, то имя компьютера w1234.
Да, это не отменяет путаницы, когда пользователь один, компьютеров два, телефонных аппаратов два, а номер один, но такие пользователи уже обучены называть правильное или возможное имя компьютера.
Да, это частый метод. Этот метод имеет минус в том, что имя компьютера админам со временем лень менять.
так а зачем его менять, если телефонный аппарат мы как бы жестко привязываем к компьютеру
Ага, например админам в call центре, операторов так на 500, где у тебя сотрудники могут мигрировать по залам в зависимости от проектов и нагрузки, например. Тогда проще таки привязать имя пк и номер телефона — имя телефона = название пк.
Не, это ужас получается. Имя компьютера должно задаваться один раз при вводе его в строй, и до самой смерти. А тут оно привязано к телефону получается. Вот сменился номер телефона — и комп перезаводить?
ну обычно номер телефона просто так не меняется, если пользователь переезжает, к примеру, то он переезжает с компьютером и своим номером телефона. Если уж как-то получилось, что номер телефона все же сменился, то компьютер переименовать придется — это 1 команда и 1 перезагрузка.
В разных компаниях применимы разные модели. Привязка к номеру телефона тоже имеет место быть. Но бывают случаи, когда телефон один на 2 компа (особенно что касается посменной работы), могут использоваться радиотрубки и другие случаи. Но если в компании всегда 100% один телефон, одно рабочее место и план телефонии утвержден и никогда не планируется меняться, то это тоже выход. У нас, например, с трудом можно привязать к номеру телефона.
Я вот думаю нафиг сменить имена пк. Ибо сейчас в них чехарда и имя ПК однозначно ни о чем не говорит.
Хотя некоторые не знают и СВОЙ рабочий номер :)
Мне кажется стоит делать так, чтобы следующий админ после тебя не говорил «Б** ну и ****!»
А: «Блин как все удобно и понятно»
Предлагаю повторно обсудить имена серверов.
Я думаю многие встречались с именами Server или Server1.
Нет понятно, что Россия и на 1 сервере очень часто крутится все что можно.
И как быть в таких случаях.
Как вариант на 1 и тот же сервер делать псевдонимы.
Так если там и DC И почта и DNS. То и сделать записи такие же. А потом будет чуть-чуть полегче разносить роли на разные сервера. Или не легче?
Хотя некоторые не знают и СВОЙ рабочий номер :)
Мне кажется стоит делать так, чтобы следующий админ после тебя не говорил «Б** ну и ****!»
А: «Блин как все удобно и понятно»
Предлагаю повторно обсудить имена серверов.
Я думаю многие встречались с именами Server или Server1.
Нет понятно, что Россия и на 1 сервере очень часто крутится все что можно.
И как быть в таких случаях.
Как вариант на 1 и тот же сервер делать псевдонимы.
Так если там и DC И почта и DNS. То и сделать записи такие же. А потом будет чуть-чуть полегче разносить роли на разные сервера. Или не легче?
Тут нет какого-то единого правила. Надо также понимать для чего все это делается. Если в компании пара серверов и 5 компьютеров, то вполне допустимо назвать сервера каким-нибудь красивым именем, а компьютеры по фамилии сотрудника. Если компьютеров много, то, возможно, потребуется учитывать много разных параметров, география, назначение, ОС, уровень подсистемы, вид железа и т.п, что именно должно быть в имени решается в каждой компании по-своему.
Я пытаюсь разделить наименования серверов исходя из географии, назначения и номера и приделываю cname, если к серверу подключаются обычные смертные, что бы для них название звучал как-нибудь красиво.
Я пытаюсь разделить наименования серверов исходя из географии, назначения и номера и приделываю cname, если к серверу подключаются обычные смертные, что бы для них название звучал как-нибудь красиво.
Спасибо за статью, реализовал!
Sign up to leave a comment.
Упрощаем жизнь администратору, ассоциируем имя пользователя и имя компьютера в автоматическом режиме в каталоге AD