Конфигурация Sun VDI обязывает использование User Directory. Это необходимо по ряду причин, в частности пользователю удобно авторизоваться один раз в глобальном LDAP/AD для получения своих прав на всех виртуальных машинах. Если же общую User Directory по какой-то причине использовать не хочется, можно воспользоваться легковесным вариантом - Sun OpenDS Standard Edition.
Установка данного продукта не вызовет особых вопросов, можно воспользоваться даже красивым GUI. Далее создаем новый Directory Server с указанием DC=tech,DC=days. Внутри нового DC создаем OU=People и CN=tuneguy. На первом этапе этого достаточно.
Дальнейшие действия лекго можно выполнить через Web-интерфейс Sun VDI. Но при попытки авторизации любого пользователя мы получали сообщения об ошибке. В процессе диагностики была выявлена небольшая фича Sun VDI. Приведу листинг команд в CLI.
Добавим новый Directory Server:
/opt/SUNWvda/sbin/vda directory-add -p auth-type=anonymous,hosts=127.0.0.1,basedn='"ou=People,dc=tech,dc=days"'
Выведем список доступных пользователей:
/opt/SUNWvda/sbin/vda user-search
NAME KIND DN
test2 User cn=test2
test3 User cn=test3
tuneguy User cn=tuneguy
Не выводится? Тогда необходимо заменить ldap-фильтры, используя рекомендуемые параметры для OpenDS.
#/opt/SUNWvda/sbin/vda settings-getprops -p \
ldap.user.object.filter,ldap.user.search.filter
ldap.user.object.filter: (&(|(objectclass=user)(objectclass=person)
(objectclass=inetOrgPerson)(objectclass=organizationalPerson))(!(objectclass=computer)))
ldap.user.search.filter: (|(cn=$SEARCH_STRING)(uid=$SEARCH_STRING)(mail=$SEARCH_STRING))
#/opt/SUNWvda/sbin/vda settings-setprops -p ldap.user.object.filter='"(objectclass=person)"'
Global Setting Name |
Description |
Recommended Value with OpenDS |
ldap.user.object.filter |
LDAP filter used to identify objects of type user |
(objectclass=person) |
ldap.user.search.filter |
LDAP filter used to search for users according a search criteria. Searches for users can be done using the user-search command or in the web administration console. $SEARCH_STRING is the place holder for the search criteria |
(|(cn=$SEARCH_STRING)(uid=$SEARCH_STRING)) |
ldap.userid.attributes |
List of comma separated LDAP attributes storing the userid value for user objects. This is used to find a user given its userid |
uid |
ldap.user.member.attributes |
List of comma separated LDAP attributes on a user object storing the groups the user is a member of |
memberof |
ldap.group.object.filter |
LDAP filter used to identify objects of type group |
(objectclass=groupofuniquenames) |
ldap.group.search.filter |
LDAP filter used to search for groups according a search criteria. Searches for groups can be done using the user-search command or in the web administration console. $SEARCH_STRING is the place holder for the search criteria |
(cn=$SEARCH_STRING) |
ldap.group.member.attributes |
List of comma separated LDAP attributes on a group object storing the users member of the group |
uniquemember |
ldap.group.short.attributes |
List of comma separated LDAP attributes on a group object storing the information for primary group membership. Primary group membership is specific to Active Directory. |
empty |
ldap.container.object.filter |
LDAP filter used to identify objects of type container. Containers can be selected as root for custom group filters in the web administration console |
(|(objectclass=domain)(objectclass=organizationalUnit)) |
ldap.container.search.filter |
LDAP filter used by the web administration console to search for containers according a search criteria, when selecting a root for a custom group filter. $SEARCH_STRING is the place holder for the search criteria |
(|(dc=$SEARCH_STRING)(ou=$SEARCH_STRING)) |
ldap.default.attributes |
List of comma separated LDAP attributes loaded in the cache when looking up an object. It should contain all the attributes used in the other filters and attribute lists. |
dc,ou,cn,uid,uniquemember,memberof |
Заработало? Тогда пробуем посмотреть информацию о конкретном пользователе:
# /opt/SUNWvda/lib/vda-client -u tuneguy
Password:
No desktop found for tuneguy
Смотрим логи:
# tail /var/cacao/instances/default/logs/cacao.0
Apr 14, 2010 12:11:10 PM com.sun.vda.service.core.UserDirectory getDnFromUserId
FINEST: thr#64 userId=tuneguy -> DN=null
Смотрим вывод truss:
# truss -f -w all -r all -p 5609
5609/35: read(22, " 0", 1) = 1
5609/35: read(22, " E", 1) = 1
5609/35: read(22, 0x052AD800, 69) = 69
5609/35: 0201\r c @0419 o u = P e o p l e , d c = t e c h , d c = d a y s
5609/35: \n0102\n01030201\00201 y0101\0A3\r0403 u i d0406 t u n e g u y 005
5609/35: 0403 1 . 1
5609/35: write(18, "\0", 1) = 1
5609/1: read(17, "\0", 200) = 1
5609/35: write(22, 0x0538D170, 46) = 46
5609/35: 0 ,0201\r d '04 # c n = t u n e g u y ,ou=People,dc=tech,dc=days
5609/35: write(22, 0x0538D170, 14) = 14
5609/35: 0\f0201\r e07\n01\004\004\0
Смотрим в ldap.user.search.filter:
# /opt/SUNWvda/sbin/vda settings-getprops -p ldap.user.search.filter
ldap.user.search.filter: (cn=$SEARCH_STRING)
Натыкаемся на интересную фичу. Даже при явном указании в фильтре поиска параметра CN, у сервера запрашивается поле User ID, которое конечно же не заполнялось при создании пользователя. Исправляемся и указываем userid=tuneguy. После чего назначаем пользователю десктоп:
/opt/SUNWvda/sbin/vda user-assign -d 4 cn=tuneguy User cn=tuneguy assigned to desktop 4
Проверяем, что десктоп назначен:
# /opt/SUNWvda/lib/vda-client -u tuneguy
Password:
desktop=127.0.0.1:49869
id=4
rdpConfig=
cardRemovedActionTimeout=300
Приятного использования Sun VDI!