Google Apps на службе образования. Часть 3. Работа с пользователями

Как видно по названию, сегодня пойдет речь о работе с учетками. Как заводить пользователей, как с ними работать, что в этом плане дает Google, а что не мешало бы дать.
Начнем. Приблизительно так у нас выглядит часть админ панели отвечающая за пользователей:

Как видно из скриншота, к сему моменту мы уже +/- настроили. Теперь подробнее.

Google позволяет организовать работу с пользователями путем создания “орагнизаций”. Вложенность у подорганизаций может быть практически любой (по крайней мере мы пока не уперлись), но при этом, в отличии от того же MS Active Directory, один и тот же пользователь, не может входить в состав сразу нескольких организаций. Это накладывает свои ограничения, но в принципе на данном этапе не сверх проблемно.

В нашем случае, на данный момент у нас 4е корневых организации:

• Admins
• Students
• Teachers
• Tools

Думаю по названиям вполне понятно какая за что отвечает кроме последней. Об этом чуть позже. Корневая организация (tmm-sapr) кроме упомянутых suborganizations имеет одну постоянную запись – базовая запись системного администратора всея домена. В группу же Admins включены реальные люди, пусть и обладающие схожими правами.

В разделе  tools заведены вспомогательные аккаунты, для работы с сайтом, блогами, для проведения студенческих конкурсов и различных семинаров-олимпиад-конференций. В зависимости от желания и потребностей их либо проверяют вручную, либо настраивают автопересылку на свою почту. Но так как в почте ответственных товарищей, несмотря на все попытки систематизации все равно от обилия “нужного” спама в скором времени возникает дикий бардак. То эти спец. аккаунты позволяют упростить целенаправленный поиск информации и писем.

Раздел Teachers. Один из самых трудно заводимых разделов, ибо студентов то хоть пнуть можно. А вот с преподавателями хуже. Доходит до смешного.  Так например выдержка из реального разговора:

• Админ: –%ИО_1%, заведующий сказал завести всем преподавателям кафедральную почту и переводить общение на данную платформу.
• ИО_1: А оно мне нужно? меня вполне устраивает моя почта (Рамблер, яндекс, гугл, мылру – на выбор).
• ИО_2: И че ты ото будешь как последняя лоша…дка без почты? У всех уже есть! А у тебя еще нет!!!
• ИО_1: Да? НУ тогда %админ% заводи: %логин%

Кстати, должен сказать что подобные доводы от других представителей коллектива – являются гораздо более сильными нежели все объяснения о преимуществах. Все таки “Слабо” у нас в крови сидит сильно.

Что касается студентов. Как уже ранее рассказывалось, у нас для “именования” студентов есть уже одно устоявшееся правило, а именно:

SYXX – «идентификатор студента» буква обозначает принадлежность к той или иной кафедре/ыпециальности (наша просто s, у других студентов в дополнение к S появляются дополнительные буквы), Y – номер группы (в нашем институте номер группы зависит от года поступления и не меняется в течении всей учебы), на а XX – номер по списку (изначальный список группы, номер студента мы также не меняем).

Данный идентификатор является единым и для учеток на кафедре, и для учеток на кафедральной почте. Естественно, что в группах временами происходят изменения: меняются номера по списку, кто-то вылетает, кто-то приходит в группу (особенно на младших курсах), однако на логины это не влияет. Т.е. если человек продолжает учиться в своей группе – до конца учебы его номер вполне конкретен. Если же в группу приходят новые студенты – они добавляются в конец списка.

Изначально мы вводили логины по просьбам студентов (пока их было мало), но почти сразу т.е. 8 лет назад мы поняли, что это не лучший вариант ибо в логинах легко запутаться, они часто повторяются, да и вообще выглядят не всегда презентабельно. Тут Вам и чебурашки, и медведы, и найтмены, и бешенные и многие другие. С повторяющимися тоже бывает сложно: андрей, андрий, антон, тоша, тоха… и куча других “уникальных ников”. Так что уже почти 8 лет назад, еще при прежних администраторах у нас возникло четкое вышеозвученное правило, и оно настолько сразу облегчило жизнь, что при создании почты, мы теперь не сильно задумывались и перенесли его же на кафедральную почту.

Преподавательские логины в этом плане имеют чуть больше свободы, но все равно рекомендуется ставить в качестве отправных точек – ФИО. Так всем, особенно студентам проще.

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

Это немного утяжелило систему, и ее администрирование, но тем не менее уже дало первые положительные плоды.

Также у нас внутри Students есть еще одна суборганизация – deleted. Это “организация” в которую переносятся студенты, которые по разным причинам покинули учебный процесс – вылетели, закончили на 4м курсе и решили не продолжать, перевелись на другие кафедры.

***

Коротко о проблемах. Текущее правило для нарекания неофитов вводилось без учета “проблемы 2000го года”. В том плане, что спустя 10 лет, у нас снова появятся s4xx, как уже были в 2004 году, и нам придется немного модифицировать правило названий. В связи с этим, тем кто пойдет по нашим стопам настоятельно рекомендую продумать данный вариант. Поверьте – 10 лет пройдут незаметно. И если бумажные дела столько не хранятся, то некоторые электронные документы – могут вызвать проблемы. В принципе это не сверхпроблема, и всегда можно изменить первую букву (в нашем случае S), или добавить в конце букву, или еще что… но в целом о проблеме следует подумать.

Следующая проблема тоже относится к организационным. Не только преподаватели с трудом меняют свои устоии. Так группа, чей список можно увидеть на первом рисунке, является одной из наиболее активных в сетевом общении. Но почти все оно начиналось тогда, когда о домене только шли рассуждения по принципу – надо. И не смотря на “угрозы, и предупреждения”, до сих пор большинство не спешит переходить на новую почту.

Казалось бы и в чем проблема? Но дело в том, что подобное игнорирование приводит к бардаку (не всегда знаешь где что искать), дублированию действий и информации. А следовательно негативнее влияет на весь процесс, чем даже отсутствие вообще какой-либо автоматизации. Это как ручное редактирование чертежей оторванных от модели. Вроде как все на компьютере, а актуальности – нет. Кто понимает минусы подобного подхода – тому объяснять ничего не  надо. Кто не понимает – все равно не поймет.

Что еще не всегда удобно – организации и суборганизации нельзя сортировать,– они всегда идут общим списком в алфавитном порядке. Пользователи сортируются по алфавиту согласно логину.

иду дальше .

Для каждой из групп можно провести тонкую настройку доступа к сервисам. Всего гугл предлагает 7 базовых и 61 (на текущий момент) дополнительных приложений. Тут же размещаются настройки для приложений установленных через маркет.

В принципе это можно сделать и для конкретного пользователя, но потом возникает путаница, по сему лучше делать для всей группы. В принципе Вы сами решаете какие возможности давать своим студентам и сотрудникам, мы своих не особо ограничиваем и оставляем “all inclusive”. Единственное что приходится выключать это Google+ для младших курсов. Причина тому простая – лицензионное соглашение говорит, что пользователь G+ должен быть старше 18 лет. Делаем так дабы избежать соблазнов.

С гуглоплюсом связаны ряд историй и проблем, но это тема не текущей публикации.

Идем дальше. Пользователей можно создавать вручную, либо автоматизировано. В обоих случаях все созданные пользователи размещаются в корневой организации, и их потом необходимо перемещать в их личную суборганизацию. Внутри суборганизации создать пользователя можно только в ручном режиме (без автоматизации).

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

Информацию по аккаунтам из корневой группы можно загрузить в текстово-табличном виде. Об этом будет чуть позже.

При ручном создании пользователя, он помещается в ту “дирректорию” (суборганизацию) в которой Вы нажали “Create New User”

Как видно настройки – максимально простые. Имя, Фамилия, Логин – всё. При необходимости, разве что можно изменить временный пароль. Временный пароль, который создает сам гугл – достаточно зубодробителен, и нужен только для первичного логина пользователя, потом его все равно нужно менять. Ограничений на то чем заполнять первые два поля – нет. Кирилицу понимает вполне нормально. На третье поле (логин) классические ограничения.

После создания нового аккаунта его атрибуты (логин, пароль..) можно выслать по почте тому (тем) для кого данный логин создавался. Можно посмотреть временный пароль.

Аккаунт создан, помещен в нужную группу с определенными правами доступа, пользователь залогинился первый раз (об этом позже)… и вот тут возникает несколько вопросов:

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

Администратор не имеет доступа к почте и файлам пользователей организации. Не смотря на наличие кнопки “Show Password”, администратор не имеет возможности увидеть пароль к аккаунту. И следовательно данные пользователей вполне защищены. Злополучная кнопка “Show Password” доступна до тех пор, пока пользователь не залогинится первый раз.

Так как пользователи очень часто имеют привычку (можно даже сказать обНыкновение) “забывать” пароли, то естественно немаловажным пунктом является возможность установить пароль вместо пользовательского. Собственно со стороны администраторов это и есть единственный способ заполучить доступ к почте… осталось только выяснить зачем оно им…

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

Вот так выглядит окно отвечающее за информацию о пользователе и его настройках. В нем хорошо видно, что увидеть пароль установленный пользователем – нельзя. Только изменить. Если существует опасность, что пользователь где-то оставил себя залогиненым, где не надо – то можно обнулить куки. Также можно убедиться в том, является ли пароль пользователя “сильным”. Кстати для организации можно настроить правила для паролей (например длину). Кстати раз уж зашла речь о паролях – небольшой глюк. Пароли на кирилице Google считает слабыми вне зависимости от длины. В данном случае пароль считается подходящим.

Далее идет настройка расшаривать ли данному пользователю адресную книгу организации. По умолчанию, если включена опция общих контактов – то они расшариваются для всех. Общие контакты – вовсе на значит что все контакты в организации будут общими. Ваши контакты – останутся Вашими. Просто в дополнение к ним, Вы получите (или раздадите) справочник контактов “свыше”. Это достаточно удобный пункт, хотя и реализован не лучшим образом. Впрочем об этом позже.

Также пользователю можно назначить дополнительные “Nickname”. По сути это способ создать несколько почтовых адресов для одного аккаунта.

Также выводится информация о гуглогруппах в которых участвует пользователь, и том как осуществляется работа почты (например ее пересылка) . Что касается груп – там есть свои особенности, но о них будет несколько позже.

Resolved Settings – позволяет произвести тонкую настройку доступа к приложениям, если для данного пользователя их нужно сделать отличными от общих по суборганизации. В остальном не отличается от описанного выше.

В разделе Security – можно посмотреть настройки безопасности, выставленные пользователем (например включена ли двухэтапная верификация), созданы ли пароли для приложений, и к каким приложениям было выполнено подключение. В последнем случае в качестве приложений выступают и те которые доступны из маркета для организаций, и те что пользователь подключает в гуглоплюсе, и те что пользователь подключает в Chrome или в GDrive. В случае если обнаруживаются “левые” приложения не соответствующие политке безопасности организации – их можно отключить “в один клик”

Последняя вкладка Roles & Privileges настраивает возможности пользователя по выполнению административных функций. В принципе там достаточно настроек, чтобы переложить большую часть обязанностей на тех же старост и других преподавателей… Однако проще все делать крайне ограниченной группой в 1-3 человека. Иначе будет бардак.

На картинке представлены основные настройки роли администратора. Пользователь отличается полным отсутствием “галок”.

***

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