Опытные мелочи-5, или «Групповые радости!»

    image Продолжение «опытных мелочей». Предыдущие части: раз, два, три, четыре.

    В этом посте поговорим о группах в Active Directory. Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно. Поговорим о том, зачем вообще бывают нужны группы и о какие «вкусности», можно получить с их помощью.


    • Используйте группы везде, где можете, вместо отдельных пользователей. В ACL, разрешениях, выдаче прав, групповой политике и т.д. Даже если в группе сейчас только один человек — все равно, используйте группы. Это не только ускоряет работу системы (например ACL из 2-3 групп и ACL из 15 пользователей обрабатываются совсем не одинаково по времени), но и в дальнейшем сильно облегчит управление. Вам не потребуется вспоминать где и как вы назначали то или иное право, у вас будет единая консоль ActiveDirectory, в которой вы просто добавите нового человека, или удалите старого из группы, и все. Настройка завершена.
    • Называйте группы осмысленно, пишите подробную информацию в Description, используйте префиксы. Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW, а группы доступа в интернет I_FullAccess. Префикс позволит быстро находить группы в AD (жмете добавить пользователя в группу, и по префиксу сразу находится список именно тех групп, которые вы ищете). Осмысленное название и описание в Description позволит вам (или уже не вам) через полгода\год\ит.д. вспомнить смысл, который вы вкладывали в созданную группу.
    • Не увлекайтесь вложенными группами. Это полезная вещь, но если переусердствовать, то можно прийти к циклической вложенности и сами себя запутаете.
    • Делегируйте управление группами. Вынесите все ваши группы в отдельное структурированное OU и делегируйте права на управление членством в группах тем, кто за это отвечает. Например принимать у нас делегировано управление доступом в папки секретарям, а управление разрешением на удаленный доступ — в СБ. Вся волокита по «напиши служебку — подпиши ее у ответственного — ок вот мы тебя добавили — вот тебе инструкция — служебку в архив» передана им, и часть рутины ушла из отдела ИТ.
    • Используйте группы творчески, например для назначения каких либо привилегий, раздачи принтеров, раскладывания ярлыков на рабочих столах, прописывание баз 1С с помощью логон-скриптов и т.д. Учитывая, что группа в AD это довольно «емкий» объект, можно хранить прямо в них различные настройки, параметры — передаваемые скрипту при выполнении. Логика работы таких скриптов такова:
      1. Скрипт определяет в каких группах состоит данный пользователь
      2. Выбирает конкретные группы по заранее определенному признаку (например по префиксу!)
      3. Вытаскивает из этих групп «параметры» (поле Description, название группы без префикса и т.д.) и запускает внешнюю команду, или процедуру с этими параметрами

    В качестве примера приведу скрипт, который работает по этому принципу: определяет в каких группах состоит пользователь, находит среди них группы с префиксом RDP_, и создает у человека RDP-ярлык на рабочем столе с следующими параметрами:
    • Название ярлыка равно названию группы без префикса,
    • имя целевого сервера, на который ссылается RDP-ярлык записано в Description группы.
    В результате, чтобы пустить кого-то на сервер 1С, достаточно добавить его в группу, и попросить перезайти в систему. Кроме всего прочего на бухгалтерском терминальном сервере удаленный доступ разрешен только Администраторам и членам групп RDP_GroupName.

    ' Скрипт создает на рабочем столе пользователя RDP-ярлык удаленного подключения, базируясь на членстве в группах.
    ' Шаблон названия группы - RDP_НазваниеЯрлыка в поле Description указываем имя сервера, на который настраивается RDP-соединение
    ' например AD-группа RDP_1C-Бухгалтерия с описанием Server1.domain.local в поле Desription
    ' Если ярлык с таким названием уже есть - он пересоздается, что решает задачу обновления параметров.
    ' при необходимости параметры RDP-файла можно поправить в теле скрипта.
    On Error Resume Next
    Set wshShell = WScript.CreateObject("WScript.Shell")
    Set m_FSO = CreateObject("Scripting.FileSystemObject")

    ' Находим пользователя в AD и определем его параметры
    Set objSysInfo = CreateObject("ADSystemInfo")
    ADSPath = "LDAP://" & objSysInfo.UserName
    Set objUser = GetObject(ADSPath)
    ShortUserName = objUser.SamAccountName
    DomainName = objSysInfo.DomainShortName

    ' Читаем путь к Рабочему столу
    DesktopPath = wshShell.SpecialFolders("Desktop")
    LevelCount = 0
    MaxLevelCount = 4
    Status = CheckGroups(ADSPath)

    ' дальше идет нудный перечень используемых функций
    '============ Function GetPrefixNameGroup ============
    Function GetPrefixNameGroup(sString)
    ' Trim prefix of name group
    Dim TempString
    TempString = Left(sString, InStr(sString, "_"))
    GetPrefixNameGroup = TempString
    End Function
    '=====================================================
    '============ Function GetLinkNameGroup ============
    Function GetLinkNameGroup(sString)
    ' Trim LinkName of name group
    Dim TempString
    TempString = Mid(sString, InStrRev(sString, "_")+1)
    GetLinkNameGroup = TempString
    End Function
    '=====================================================
    '============ Function Create RdpFile ============
    Function CreateRDPFile(sString, sName)
    spath = DesktopPath & "\" & sString & ".rdp"
    ' проверяем наличие такого же файла - если есть - удаляем его'
    If m_FSO.FileExists(sPath) or m_FSO.FolderExists(sPath) Then
    m_FSO.DeleteFile (sPath),1
    End If
    Set RDPFile = m_FSO.CreateTextFile (spath, True)
    RDPFile.writeline ("screen mode id:i:2")
    RDPFile.writeline ("use multimon:i:0")
    RDPFile.writeline ("desktopwidth:i:1280")
    RDPFile.writeline ("desktopheight:i:1024")
    RDPFile.writeline ("session bpp:i:16")
    RDPFile.writeline ("winposstr:s:0,1,0,0,800,600")
    RDPFile.writeline ("compression:i:1")
    RDPFile.writeline ("keyboardhook:i:2")
    RDPFile.writeline ("audiocapturemode:i:0")
    RDPFile.writeline ("videoplaybackmode:i:1")
    RDPFile.writeline ("connection type:i:2")
    RDPFile.writeline ("displayconnectionbar:i:1")
    RDPFile.writeline ("disable wallpaper:i:1")
    RDPFile.writeline ("disable full window drag:i:1")
    RDPFile.writeline ("allow desktop composition:i:0")
    RDPFile.writeline ("allow font smoothing:i:0")
    RDPFile.writeline ("disable menu anims:i:1")
    RDPFile.writeline ("disable themes:i:1")
    RDPFile.writeline ("disable cursor setting:i:0")
    RDPFile.writeline ("bitmapcachepersistenable:i:1")
    ' добавление имени сервера '
    RDPFile.writeline ("full address:s:" & sName)
    RDPFile.writeline ("audiomode:i:2")
    RDPFile.writeline ("redirectprinters:i:0")
    RDPFile.writeline ("redirectcomports:i:0")
    RDPFile.writeline ("redirectsmartcards:i:0")
    RDPFile.writeline ("redirectclipboard:i:1")
    RDPFile.writeline ("redirectposdevices:i:0")
    RDPFile.writeline ("redirectdirectx:i:1")
    RDPFile.writeline ("autoreconnection enabled:i:1")
    RDPFile.writeline ("authentication level:i:0")
    RDPFile.writeline ("prompt for credentials:i:0")
    RDPFile.writeline ("negotiate security layer:i:1")
    RDPFile.writeline ("remoteapplicationmode:i:0")
    RDPFile.writeline ("alternate shell:s:")
    RDPFile.writeline ("shell working directory:s:")
    RDPFile.writeline ("gatewayhostname:s:")
    RDPFile.writeline ("gatewayusagemethod:i:4")
    RDPFile.writeline ("gatewaycredentialssource:i:4")
    RDPFile.writeline ("gatewayprofileusagemethod:i:0")
    RDPFile.writeline ("promptcredentialonce:i:1")
    ' добавление имени пользователя в нотации Domain\Username'
    RDPFile.writeline ("username:s:" & DomainName& "\"& ShortUserName)
    RDPFile.writeline ("drivestoredirect:s:")
    RDPFile.close
    End Function
    '=====================================================
    '============ Function CheckGroups ===================
    Function CheckGroups(ADSPath)
    Dim objUser, arrMemberOf
    Const E_ADS_PROPERTY_NOT_FOUND = &h8000500D
    LevelCount = LevelCount + 1
    if ( LevelCount >= MaxLevelCount) then
    LevelCount = LevelCount - 1
    return LevelCount
    end If
    Set objUser = GetObject (ADSPath)
    On Error Resume Next
    arrMemberOf = objUser.GetEx("memberOf")
    If Err.Number = E_ADS_PROPERTY_NOT_FOUND Then
    LevelCount = LevelCount - 1
    return LevelCount
    Else
    For Each Group in arrMemberOf
    ADSGroup = "LDAP://" & Group
    CheckGroups(ADSGroup)
    WScript.Echo "Extra=" & LevelCount
    Set objGroup = GetObject ( ADSGroup )
    If(GetPrefixNameGroup(objGroup.CN) = "RDP_") Then
    Set objGroup = GetObject ( "LDAP://" & Group)
    LinkName = GetLinkNameGroup(objGroup.CN)
    LinkServer = objGroup.description
    LinkResult = CreateRDPFile (LinkName, LinkServer)
    end If
    Next
    End If
    LevelCount = LevelCount - 1
    End Function
    '=====================================================

    А, чтоб не повторятся простыней скрипта, и вдобавок для разжигания «праведного любопытства сисадмина» примером номером два пойдет скриншот из AD.
    image
    Здесь используется аналогичный скрипт для добавления пользователям баз 1С. Причем, как нетрудно догадаться, с частью баз пользователи работают в терминале (в двух разных) и скрипт добавления путей запускается на самом терминале, поэтому пути локальные. С другой частью баз (зарплатные) — через сеть, и скрипт запускается на рабочих станциях, что в общем то неважно, ему все равно какие пути добавлять пользователю. Если будете сами делать подобное — не забывайте, что в 1С7.7 и в 1С8.Х — разные принципы добавления путей к базам, соответственно нужны либо разные скрипты, либо две разные функции в теле скрипта.
    А еще лучше прямо запуск самой 1С делать через такой скрипт, который сначала пропишет все что нужно, а потом запустит программу.

    Продолжение следует

    P.S. подскажите пож. Как на Хабре лучше выкладывать скрипты и вообще код, а то больно длинный пост получается.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 23

      +1
      А зачем нужен скрип создания rdp файла? Не проще создать один раз их сохранить их в общедоступном месте и размещать у пользователя через group policy только линки на них?
        +1
        Этот скрипт был написан, когда Group Policy Preferences мы еще не использовали, и чтобы раздать ярлыки на сетевые RDP-файлы все равно нужно было писать логон-скрипт, который эти «ярлыки на ярлыки» создавал бы. Мы решили не городить огород и создавать сразу RDP-файлы.
        С одной стороны некоторая отказоустойчивость (если недоступен файловый сервер, то все равно можно зайти в терминал поработать, ага?)
        С другой тут важен не процесс создания RDP-файла, а именно управление кому какой ярлык на основе членства у группе. У нас было тогда довольно много разных терминалов, и разных групп людей, которым нужно было одно, но не нужно было другое, а через полгода ситуация менялась в обратную сторону. Написанный скрипт позволил делегировать управление членством в группах RDP_ ответственному лицу, начальнику их отдела, и этот вопрос свалился с наших плеч.
        Ой, что это я. Не свалился — был делегирован :)
        0
        А с группой компьютеров такое прокатит? Например поставить принтер определенной группе компьютеров. Ведь компьютеры трактуются как «особый» пользователь АД?
          0
          прокатит.
          ну и не нужно наверное напоминать что в этом случае в группе должен состоять компьютер, и скрипт должен запускаться в разделе компьютера (Group Policy — Computer Configuration — Windows Settings — Scripts ) а не пользователя.
            0
            А если что-то давать компьютерам устанавливать из UNC пути — какие права пользователей должны быть в этом пути? Authenthicated Users достаточно или там другой уровень?
              0
              Достаточно. Но практика — критерий истины. Просто возьмите и попробуйте.
              Помните что Authenthicated Users это весьма широкое понятие, и лучше придерживаться правила: «давать только необходимое».
              Я бы лично дал бы права той группе, спомощью которой вы ставите софт.
              Ну вот например:
              • сделали группу UNC_MegaSoft, чтобы устанавливать ваш MegaSoft по UNC путям.
              • написали скрипт, который устанавливает все что нужно для тех, кто входит в группу UNC_MegaSoft
              • добавили в эту группу ряд компьютеров.
              • тогда логично будет назначить на шару права для группы UNC_MegaSoft. убрав все лишнее. В этом случае у вас гарантированно будут права для тех, кому скрипт будет ставить ваш софт, и не будет прав у тех, кто не в группе, и кому это не нужно.
                0
                В принципе достаточно логично, я просто имел ввиду о том, что ведь компьютер — это хоть и учетка, но как он эээ… аунтетифицируется?
                Я попробовал, только не могу понять, сработало или нет :)
                Спасибо за идею и описание!
                  +1
                  Компьютер это такая же (ну почти) учетка как и пользователь. И у него тоже есть пароль :)
                  А что вы никогда не сталкивались с ситуацией что если доменный компьютер некоторое время не включался в сеть, то потом он отказывается входить в домен? Это его т.н. пароль истек.
          0
          Автору спасибо, давно хотел посмотреть нормальный пример использования AD + GPO.
          Также + за хорошую идею насчет использования групп везде где можно.
            +1
            Рекомендую почитать на эту тему книжки цикла Best Practise (хотя бы про тот же AD). Там все описано. И про теневые группы и про планирование групп/политик/подразделений…
            +1
            Статья годная. Но тема глобальных, универсальных и локальных групп, а так же модели A-G-DL-P — не раскрыта.
              +2
              Зачем? Это и так всё раскрыто в любой самой захудалой книжке по началам работы с AD…
              Я вот правда всё время забываю их разницу, т.к. редко приходится сталкиваться :)
            +1
            Спасибо за цикл статей, с удовольствие прочитал, несмотря на то что не всё может потребоваться в работе.

            Пишите ещё!
              0
              Использование совета под номером 1 в одной достаточно большой организации привела к тому, что у некоторых пользователей перестали работать внутренние веб-приложения с Kerberos-аутентификацией. Оказалось, что рост числа групп привел к слишком большому размеру Kerberos-токенов. Microsoft-у пришлось вносить изменения в наши конфигурации Exchange и Sharepoint. Сейчас балансируем где-то у верхней границы supported Token Size.
                +1
                я много раз писал и видимо буду продолжать писать о том, что мой опыт связан с небольшими организациями. Это накладывает свой отпечаток.
                Кроме того, первый совет о том, что в ACL, Group Policy и иже с ними лучше использовать группы, а не отдельных людей. В вашей же ситуации проблема была в слишком большом числе групп. Это несколько разные вещи, не находите?
                Да, возможно и такое, наверное это даже не экстремально, а действительно необходимо в ОЧЕНЬ большой организации, но это ведь не умаляет достоинства использования групп в сравнении с пользователями? М?
                Кстати, а у проблемных пользователей сколько групп было? И какой уровень домена-леса? Интересно :)
                  +1
                  проблема была все-таки не в общем колличестве групп в AD, а в том, что некоторые пользователи находились с слишком большом количестве групп (то есть под каждую задачу создавали группу, даже если в ней был всего один человек). Насколько я знаю, речь шла около 1000 групп у одного пользователя. И вот от этого я хотел бы предостеречь ))
                0
                Как на Хабре лучше выкладывать скрипты и вообще код, а то больно длинный пост получается.

                pastebin.com
                gist.github.com
                  0
                  «В результате, чтобы пустить кого-то на сервер 1С, достаточно добавить его в группу»

                  как уже правильно заметили, создавать группу по каждому чиху тоже может стать накладно.
                  может быть я невчитался в статью, но не увидел рекомендации создания групп по ролям.
                  например, те же бухи, которые ходят по рдп на терминал с 1с: создав группы FLD_1c и RDP_1c, на мой взгляд логичнее добавить группу «Бухгалтерия» и включить обе эти группы туда. а самих пользователей уже банально добавлять в «Бухгалтерия». плюс, не надо думать «а какой же группой у нас ставится RDP-ярлычок?», «а какой же группой даются права на SQL?» и прочая прочая.

                  получается простая схема: есть отдел, есть функционал отдела — есть группа отдела. приходит человек — попадает в группу отдела и имеет щастье.

                  «А еще лучше прямо запуск самой 1С делать через такой скрипт»

                  кстати о скриптах — я уже давно для себя решил, что чем меньше скриптов и чем больше готовых решений используется, тем меньше проблем. начиная с такой мелочи, как «ушел человек, который писал этот скрипт полжизни». касательно конкретно 1с — 7рка отлично настраивается через политики с реестром, 8рка — через плагин к AD, который так же через GPO прописывает нужные базы. и опять задача сводится к «пришел дцатый бух, добавили его в группу бухов и группу бухов по функицоналу (ЗП, ОС и тд)». бух запустил комп — все нужное есть сразу.

                  с другими шедеврами «программизма» конечно сложнее. особенно с поделками, которые хотят админские права и писать исключительно в C:. но это уже отдельный разговор. (и таки да, к сожалению, эти шедевры стоят денег и там низкая конкуренция).

                  касаемо ярлычков, принтеров и прочая — с приходом GPP потребность в скриптах практически свелась к нулю. а настроить рабочий стол, на мой взгляд, гораздо более правильно через стандартный профиль. в этом случае, опять же, достаточно просто скопировать профиль и поправить права на скопированном. дальше юзверь грузится и засасывает готовый профиль с сервера.

                  «Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW»

                  кстати, было бы интересно посмотреть на схему таких групп, когда права на ресурсы назначаются на 3+ уровней вглубь дерева папок. например, «депаратамент — отдел — группа — проекты». у меня получалась уж очень сложная схема. хотя это и было лучше, чем назначать права на папки ручками. плюс, возник такой ньюанс — если называть группы осмысленно, по названиям папок, в какой-то момент упираемся в ограничение на длину имени группы. (группы создавались автоматом, на основе дерева шары)

                  опять же, предложенная схема «FLD_Foldername» явно заточена под то, что все ресурсы лежат в одном корне DFS? а какие решения были выработаны для случаев, когда права нужно давать на конкретном сервере? или если в лесу несколько доменов/несколько лесов (подразделения/афф конторы)?

                  «Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно»

                  наверное, стоит немного упомянуть об их функционале? все-таки, если организация работает в одной локалке это одно, а если подразделений по регионам кучка — вопрос групп уже может стать острым. и дело даже не в трафике репликации. а банальной скорости доступа к объектам и тп.
                    0
                    Ну тут конечно можно спорить, и конечная реализация сильно зависит от нужд самой компании.
                    если конкретно, то
                    — ваш метод «делаем одну две группы и назначаем им необходимые права которые одинаковы для всех (Бухгалтерия=1C+RDP+папкаБухгалтерия+т.д.)» мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами. а если человек бухгалтер, а ему не все базы нужны, или продажник но по отдельному направдению, или бухгалетр, но без доступа к терминалу и т.д. Я считаю лучше сделать множество групп, и потом из этих групп-кирпичиков «строить» каждому пользователю его личное «множество прав». Это более избирательно и гибко на мой взгляд.
                    — чтобы достигнуть ситуации как описывал выше makc_de, надо сильно постараться. 1000 групп у человека это конечно перебор. По опыту (а я не устаю напоминать какой он у меня, в организациях какого размера полученный) больше чем 200-300 групп (вообще! не у одного пользователя) в организациях среднего размера не было ни разу.
                    — отношение к скриптам у каждого свое. иногда скрипты полезны, иногда готовое решение дорого или недостаточно функционально, а иногда наоборот скрипты кривы и только ухудшают ситуацию. Тут единого рецепта наверное нет.
                    — назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд. Если нужна группа для коллективного доступа — выносите ее выше, максимум на 2 уровень, зачем глубже то? Ну и то же самое касается названий папок. У нас было единой для всех правило: если папка имеет особые права, то она называется по английски и одним словом максимум 2-3 словами без пробелов. Поэтому проблем особых мы как вы понимаете не испытывали
                    — когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS? Мы всегда придерживались этого правила, и не столкнулись с ситуацией когда его невозможно было бы применить.
                    — когад в лесу несколько доменов, или вообще несколько лесов, то это не в моем посте нужно описывать :) Это уже не «небольшие организации».
                    — написать про различия между группами, и применении их на практике… ох. напишу, но потом. :)

                    Спасибо за критику, единственно прошу, не забывайте про неуниверсальность этих статей. Все таки есть определенная разница между решениями для 300 пользователей и решениями для 3000 пользователей.
                      0
                      перечитал свой коммент — действительно как-то резковато получилось. прошу прощения.
                      тема несколько зацепила :)

                      «мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами»

                      не совсем так. с тем, что собирать «по кирпичикам» гораздо правильнее и надежнее, я с вами абсолютно согласен. только вот когда движуха персонала человек 10 в месяц и больше — на кирпичики уходит неприлично много времени. да и риск ошибок возрастает. (хотя конечно, если в конторе со 100 человеками 5+ админов, это смешные цифры. а если 1-2...)
                      плюс, опять же, если структура конторы меняется каждые полгода, перепахивать права на каждом юзвере по отдельности — еще та задачка. даже если раз в год — неделя обычно выкинута на изменения и устранения косяков. даже если членство в группах менять не руками, а через скрипты.

                      плюс, просто может быть у меня не было такого, чтобы 1 бух мог работать с 1с, а другой такой же нет. т.е. внутри отдела/группы отдела, функционал был одинаковый.
                      что же касается «индивидуальных прав» — группы «бух зп», «бух ос» и тд. и есть те самые нужые права из «множества, доступных отделу/департаменту». например, у вас 3 расчетчика, 3 на ОС и тд. весьма маловероятно, что один расчетчик будет ходить на терминал, а другой работать с ПК. аналогично и с другими.

                      если отвлечься от бухов, возьмем например, «сметчик» и «сметчик выездной». можно набрать «по кирпичикам» права каждому сотруднику (СПО, ФС, БД, РДП/ВПН, НОУТ), а можно наполнить обе роли и конкретному сотруднику дать одну из них. или сделать роли дополняющими: «сметчик» + «мобильный сотрудник».
                      при первом варианте мы даже сможем легко давать отчет руководству «сколько у нас мобильных сотрудников такого-то отдела» и тп. при втором варианте, ответить тоже сможем, но уже нужно будет искать пересечение множеств.
                      и таки да, тут уже общего рецепта точно не будет.

                      и к вопросу о «кирпичиках», «сб» и тд — может быть вы отдельным постом осветите процесс изменения? т.е. те самые вопросы по «добавлению/удалению кирпичиков» людям, автоматизированность применения изменений на ПК/серверах (см. коммент ниже про «убрать ярлык») и тп. мне почему-то кажется, что при таком подходе у вас эта штука должна быть очень четко проработанной. и скорее всего, расхождение взглядов на группы связано именно с протеканием процессов изменений.

                      «назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд»

                      конторы бывают разные. почему 3+ уровня? например, есть куча департаментов, есть куча отделов, есть куча проектов. сделать «сразу хорошо», отделив проекты от отделов не всегда получается. в внутрь отделов/проектов нужно давать доступ сотрудникам других подразделений.
                      хотя конечно да, если как у вас, руководство положительно смотрит на правильную организацию хранения, такие права и не требуются.

                      «Тут единого рецепта наверное нет»

                      почему я упомянул скрипты как нежелательное — написание скриптов это уже оттенок программизма. соответственно, нужно чтобы админ имел и опыт скриптописания и желание возиться со скриптами. а при смене админов, это получается далеко не всегда. (опять же, вопрос движения персонала)
                      и в отличие от скриптов, показать инструкцию/доку от софтины гораздо проще и надежнее.
                      (и, кстати, отдельной стезей идет «самописное ПО, которое пишется отцом-основателем» и ситуация когда «отец-основатель» уходит из конторы. в лучшем случае, ПО просто перестает развиваться...)

                      «когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS»

                      в принципе согласен, если СПО не кривое, то вполне можно.

                      «Это уже не «небольшие организации».»

                      ммм… как сказать. вот скажем, есть контора. покупает другую контору. в присоединяемой организации обычно уже есть свое ИТ-хозяйство. если присоединяется не одна, а несколько контор, то и доменов уже становится несколько. и вариантов становится два: или все конторы вводить в основной лес/домен или настраивать связи между ними. если же ИТ новой конторы остается самостоятельным, то остается только второй вариант — проще дать указания по обеспечению связи, чем разгребать внутреннюю сеть.
                      и так да, речь о конторах меньше 500 человек, связанных с компами :)

                      зы: если что, это не критика, это скорее желание понять причины принятых решений, их плюсы и минусы для дальнейшего использования.
                      ззы: а на тему СКС/каналов связи у вас планируется пост-другой? было бы интересно почитать, особенно, если решения вырабатывались в процессе переездов внутри здания/в другие здания и тд.
                    0
                    Интересный подход, спасибо.
                    Как вы решаете проблему с оставшимся ярлыком после лишения пользователя членства в группе?
                      0
                      Мы — никак не решаем, т.к. это не предусмотрели просто. :)
                      А вообще, у пользователя несмотря на оставшийся ярлык, при удалении из группы пропадают права на те ресурсы куда вел ярлык. т.е. кроме захламления рабочего стола пользователя это ничем особым не грозит.
                      Ну и угроза безопасности, конечно, куда без нее.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое