Инсталиране и използване на агента за записване за Windows¶
-
Инсталиране
Инсталиране и внедряване на агента за записване за Windows.
-
Конфигурация
Конфигурирайте агента за записване за Windows да работи с RDP и HTML5 RDP приложения и/или с директен достъп.
Агентът за записване за Windows се използва от CyberElements, за да добави нови функции към сесиите RDP:
- Възможност за филтриране на потоците TCP и UDP, достъпни за потребителя
- Възможност за задействане на записване на сесията за всеки потребител, който се свързва със сървъра, без да минава през потребителския портал или клиента Desktop (функция
direct access)
Освен това по време на потребителските сесии се улавят допълнителни събития:
- Отваряне на прозорец
- Затваряне на прозорец
- Стартиране на програма
- Затваряне на програма
- Съдържание на клипборда
- Активност на потребителя
Предварителни изисквания¶
Съвместимост на клиента
За да разберете дали агентът е съвместим с различните операционни системи Microsoft Windows, вижте матрицата за съвместимост.
Агентът за записване има няколко предварителни изисквания, за да работи правилно. Някои от тях се отнасят само до функцията за записване чрез агент за приложенията RDP и HTML5 RDP, а други – до директния достъп чрез агент.
Общи предварителни изисквания¶
Агентът за записване изпраща записа на потребителската сесия обратно към CyberElements, като се свързва с компонента Edge Gateway на порт TCP 8443. Това изисква мрежовият поток между двата компютъра да е отворен.
За да изпрати сигурно записа обратно към компонента Edge Gateway, агентът за записване установява защитена връзка с него чрез TLS. TLS разчита на използването на сертификати и следните условия трябва да бъдат изпълнени, за да се счита връзката за надеждна и защитена:
- Сертификатът на сървъра, в случая Edge Gateway, не трябва да е изтекъл (максимална дата на валидност).
-
Сертификатът на сървъра, в случая Edge Gateway, трябва да е издаден от сертифициращ орган, признат за надежден от компютъра, на който е инсталиран агентът за записване.
Допълнителна информация
Сървърът, на който е инсталиран агентът за записване, трябва да има поне главния сертифициращ орган (CA) на сертификата на сървъра за записване в своето локално хранилище на доверени сертифициращи органи.
Затова е необходимо:
- Да извлечете главния CA на сертификата от услугата за записване в Edge Gateway.
- Да качите този CA на сървъра, на който е инсталиран агентът за записване.
- Да инсталирате CA в хранилището за сертификати „Trusted Root Certification Authorities“ на локалния компютър.
Пример с PowerShell
Можете лесно да импортирате сертификат във формат
.cerчрез PowerShell.
За целта отворете терминал на PowerShell като администратор на компютъра и изпълнете следната команда:Заменете1Import-Certificate -FilePath "<PAHT_TO_CERT>" -CertStoreLocation "Cert:\LocalMachine\Root"<PATH_TO_CERT>с пътя до файла на сертификата.Пример с PowerShell за сертификата на Systancia без изпращане на файлове
Този пример включва инсталиране на главния CA на Systancia, който се използва по подразбиране в CyberElements.
Възможно е също сертификатът да се импортира, без да е необходимо файлът да се изпраща/изтегля на компютъра, на който е инсталиран агентът за записване.
За целта отворете терминал на PowerShell като администратор на компютъра и изпълнете следните команди:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
# Systancia Root certificate $base64Cert = "MIIFIDCCBAigAwIBAgIBADANBgkqhkiG9w0BAQUFADCBjTELMAkGA1UEBhMCRlIx FDASBgNVBAoTC0lQZGl2YSBSb290MR0wGwYDVQQLExRJUGRpdmEgU2VjdXJpdHkg RGVwdDEqMCgGA1UEAxMhSVBkaXZhIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MR0wGwYJKoZIhvcNAQkBFg5wa2lAaXBkaXZhLmNvbTAeFw0wNTA4MjIxNTAwMzla Fw0zMDA4MjIxNTAwMzlaMIGNMQswCQYDVQQGEwJGUjEUMBIGA1UEChMLSVBkaXZh IFJvb3QxHTAbBgNVBAsTFElQZGl2YSBTZWN1cml0eSBEZXB0MSowKAYDVQQDEyFJ UGRpdmEgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxHTAbBgkqhkiG9w0BCQEW DnBraUBpcGRpdmEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA ua59tx+RkIPZbGaSwkV0w5fuPBpY3sbLTk/eR2uN7j9zMu0pq38LfibCVsNGlifh GfT5CEbrNL7KvlEVY/It1QluYxNgknlcBP1roJG/xHNcUNmbvCFYLy9N3Nd0J/gC Vd8tdB4exqyKEoNuqX18rLpSJJOUZdQCeGdF9r+w6vmHdRMeVS44qIiBPv9Bxzgf GXBxAlSqfuDDJ3eZEMsWF/kJrbm4Uhav2ACl5qjHgSSTKMoGoEWOJNkB7Mq/khxc TnixIpM2s1rpEfhIetPo4BHsyKv7wqWrS6ouwu5AbzT5t3UqaN77CLqcZJGQ3vC0 IGKBuEcwigd7W6qkX1/XMwIDAQABo4IBhzCCAYMwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQU+lu7XBGohR2DKD+D+abZEODRHjkwgboGA1UdIwSBsjCBr4AU+lu7 XBGohR2DKD+D+abZEODRHjmhgZOkgZAwgY0xCzAJBgNVBAYTAkZSMRQwEgYDVQQK EwtJUGRpdmEgUm9vdDEdMBsGA1UECxMUSVBkaXZhIFNlY3VyaXR5IERlcHQxKjAo BgNVBAMTIUlQZGl2YSBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eTEdMBsGCSqG SIb3DQEJARYOcGtpQGlwZGl2YS5jb22CAQAwCwYDVR0PBAQDAgEGMBkGA1UdEQQS MBCBDnBraUBpcGRpdmEuY29tMBkGA1UdEgQSMBCBDnBraUBpcGRpdmEuY29tMBEG CWCGSAGG+EIBAQQEAwIABzA+BglghkgBhvhCAQ0EMRYvSVBkaXZhIFJvb3QgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkgQ2VydGlmaWNhdGUwDQYJKoZIhvcNAQEFBQAD ggEBACaAgBQK7TATXieb9OdKm+l7/GpePo8f2bRKnkqeRS+HXBKYkvqVJdbJnhJm YPOdmhr9ATzt+488tQREAGzqPCp5eiVExPgvomNeG77X57KqbgCA1F7zGJqjP1FL 771FIWvFXp80ReM/zhcM+MY3sa5LADgOEl5NhoMNHT8AhLKwZ81j5nuwxyG9ICCN 5GjwgsnK/agmum4+RKeybIWuC/JTsSnu5OImXsmrlUiakp2l+VsZ1rRRNRNUlSbg Q3T8kj5ajB0lv2I0kj4fN9wDxzdHEn7nEAmv0t6Y5Te0g/VK3VWhuqeLStaahgip hmOVxbu5Ijfug5/3Eemep34NsYk=" # Convert the certificate and store it in memory $certBytes = [Convert]::FromBase64String($base64Cert) # Create a certificate object $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $cert.Import($certBytes) # Open the trusted root certificate store on the local machine and add the Systancia root certificate $store = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root", "LocalMachine") $store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $store.Add($cert) $store.Close()За да използвате този метод с друг CA, променете стойността на променливата
base64Certна кодиран в base64 сертификат по ваш избор. -
Сертификатът на сървъра, в случая Edge Gateway, не трябва да е анулиран.
- Компютърът, на който е инсталиран агентът за записване, трябва да може да се свърже със сървъра, в случая Edge Gateway, чрез DNS име или IP адрес, обхванат от сертификата на сървъра чрез неговото поле Common Name (CN).
Специфични предварителни изисквания за приложения RDP с агенти, използвани на потребителска работна станция с macOS или Ubuntu¶
Предупреждение
Следните предварителни изисквания са необходими само ако потребителят стартира приложение RDP с агент и работната му станция не е с Windows (macOS или Ubuntu).
Ако потребителите на CyberElements имат работни станции само с Windows или, ако не, използват само приложения HTML5 RDP, следните предварителни изисквания могат да бъдат пренебрегнати.
Следните ключове от системния регистър са необходими на целевия сървър, на който е внедрен агентът за записване.
Първият ключ ще деактивира списъка с разрешени програми при стартиране (документ на Microsoft). По подразбиране компютър с Windows разрешава само explorer.exe като програма при стартиране.
1 2 | |
Ако компютърът не е сървър RDS, винаги се препоръчва да се приложи следният ключ от системния регистър, за да може агентът за записване да се отваря като програма при стартиране:
1 2 | |
Специфични изисквания за директния достъп¶
Функция за директен достъп
Функцията за директен достъп ви позволява да задействате записване на сесията на потребителя при достъп чрез RDP или чрез конзола (физическа връзка с компютъра или чрез конзолния режим на хипервизора), който не минава директно през CyberElements.
Ако потребителят има разрешение за достъп до сървъра, сесията му ще бъде записана. Ако не е така, по подразбиране потребителят ще бъде прекъснат.
За да работи агентът за записване в режим на директен достъп, е необходим сертификат x509. Този сертификат трябва да отговаря на следните изисквания:
- Сертификатът трябва все още да е валиден (периодът на валидност не е изтекъл).
- Сертификатът трябва да е от типа (поле за разширено използване на ключа)
client authentication(OID: 1.3.6.1.5.5.7.3.2). - Сертификатът не трябва да е анулиран.
- Ограниченията, произтичащи от ниво на защита 2 на OpenSSL, означават, че:
- Сертификатът трябва да има частен ключ от поне 2048 бита при шифрите RSA, DSA и DH; ключовете с елиптични криви (ECC) трябва да са от поне 224 бита.
- Подписът на сертификата не трябва да бъде MD5 или SHA-1 (за предпочитане е SHA-512).
- Сървърът за записване ще използва полето
Common Name(CN), за да идентифицира сертификата, а оттам и компютъра, на който се задейства директно записване. Това поле трябва да бъде попълнено.
Използване на агента за записване с RDP и HTML5 RDP приложения¶
Активиране на използването на агента за записване¶
Ако агентът за записване е правилно инсталиран и конфигуриран, използването му се активира на ниво съответното RDP или HTML5 RDP приложение:
В механизма участват три параметъра:
Without agent mode- Тази опция трябва да остане неотметната, за да работи агентът за записване.
Disconnect session if the recorder is not working- Това активира или деактивира защитна функция, когато записването на сесията е неуспешно по различни причини. Ако записването не може да се извърши, RDP или HTML5 RDP сесията на потребителя ще бъде прекратена. Препоръчваме да активирате тази настройка, за да предотвратите връзки на потребители без записване (например при неизправност на агента за записване).
Time before disconnection- Ако предишната опция е активирана, тази опция ви позволява да зададете времето в секунди преди прекъсването на връзката. Стойността по подразбиране е 30 секунди, но може да бъде намалена за по-бърза реакция или увеличена, ако например е известно, че потребителските сесии са дълги.
Ограничаване на страничното придвижване¶
Ограничаването на страничното придвижване е функция, която ограничава мрежовите връзки на потребителската сесия. По подразбиране тази функция блокира целия TCP/UDP трафик в потребителската сесия, но администраторите могат да отварят различни потоци за достъп.
Ограниченията се конфигурират в access policy и следователно могат да варират в зависимост от потребителя и да имат различни настройки за един и същ потребител (чрез умножаване на присвоените му политики за достъп). Потребител с няколко политики за достъп за едно и също приложение ще получи мрежови ограничения според най-разрешителния достъп.
След като RDP или HTML5 RDP приложение с агент бъде включено в политика за достъп, разделът Network connections става достъпен. Оттам можете да активирате филтрирането и да посочите мрежите, до които потребителят има достъп: 
Информация
Всички промени в тези настройки ще бъдат приложени за потребителите едва при следващото използване на съответното RDP или HTML5 RDP приложение.
Конфигуриране на записването на директния достъп с агент¶
Деклариране на сървъри, подготвени за директен достъп с агент¶
За да декларирате сървър, който трябва да работи в режим на директен достъп с агент, първо трябва да отворите модула Machines management:
След това щракнете върху бутона , за да добавите нов сървър. Ще се появи нов прозорец за конфигуриране на новия сървър: 
Name- Името на компютъра, както се показва в конзолата на CyberElements.
Notification text- Съобщението за известие, което потребителите ще получат при свързване към сървъра.
Record sessions as videos- Активира или деактивира видеозаписването на сесията. Ако е деактивирано, ще бъдат прихващани и записвани само събитията от сесията.
Check video integrity at playback- При създаването на видеоархива се изчислява и съхранява хеш (SHA-256) на видеофайла. Когато администраторите преглеждат архива, се проверява дали хешът не е бил променен. Ако е бил променен, на администратора ще бъде изпратено съобщение за сигнал, тъй като вероятно има промени във видеозаписа (напр. подменени или изрязани поредици).
Allow manual removal of archives- Разрешава или забранява на администраторите да изтриват видеоархиви.
Информация
Генерираните архиви запазват настройките, които са били в сила по време на записването. Промяната на тази настройка ще засегне само новите архиви. Delete archives automatically- Настройване на автоматичното изтриване на архивите след изтичане на определен брой дни.
Информация
Генерираните архиви запазват настройките, които са били в сила по време на записването. Промяната на тази настройка ще засегне само новите архиви. Use agent mode- Опция, която трябва да бъде активирана, за да разполага сървърът с механизма за директен достъп с активен агент.
Host (CN of the certificate)- Посочване на CN на сертификата, използван от агента за записване за удостоверяване пред шлюза Edge Gateway. Това съответства на настройките на сертификата на компютъра.
Use no agent- Ако даден параметър не е полезен за желания режим на работа, отметката му може да бъде премахната.
Конфигуриране на правата за директен достъп с агент¶
Конфигурирането на правата за директен достъп с агент е подобно на конфигурирането на политиките за достъп до приложенията. Новите права се декларират, а съществуващите се променят чрез Direct recording configuration:
Можете да добавите нова конфигурация, като щракнете върху бутона .
Различните раздели с настройки са подобни на тези на политиките за достъп до приложения, с изключение на раздела за групи, който ви позволява да добавите група ръчно: 
След като щракнете върху бутона за ръчно добавяне, ще се появи нов прозорец за въвеждане на името на групата и нейния домейн: 
Съвет
Тази функция е особено полезна, ако искате да добавите локална група или група в OU, различна от зададената в конфигурациите на LDAP домейна.
Другите раздели са:
Sites: разполагане на конфигурацията в един или няколко сайта и съответно разрешаване на агента за записване да се свързва към един или няколко шлюза Edge Gateway, прикрепени към избраните сайтове.Machines: добавяне на RDP сървърите, декларирани в предишната глава.Alerts: свързване на сигнали с конфигурацията.Network connections: ограничаване на страничното придвижване на потребителите по време на техните сесии с функционалност, идентична с ограниченията на страничното придвижване за RDP и HTML5 RDP приложенията.
Дневници на агента за записване¶
Активиране на дневниците на агента за записване¶
Предупреждение!
Активирането на дневниците изисква рестартиране на услугата на агента за записване, което ще спре всички записвания на сесии, извършвани в момента на сървъра.
В зависимост от настройките на ключа LogOffOnFailure потребителят или ще бъде изведен от системата, или ще остане влязъл в нея.
За да активирате дневниците на агента за записване, трябва да изпълните следните стъпки:
-
Създайте директория с име
Logв инсталационната директория на агента (по подразбиране това еC:\Program Files (x86)\Systancia\cyberelements). -
Рестартирайте услугата
CleanroomAgent, например със следната команда на PowerShell, изпълнена като администратор:1Restart-Service -Name 'CleanroomAgent'
При всяко стартиране на услугата на агента за записване ще се генерира нов файл с дневник в директорията Log, създадена в стъпка 1.
Съдържание на дневниците на агента за записване¶
Дневниците, генерирани от агента за записване, ще изглеждат така:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | |
Инициализиране на агента за записване (редове 1-21)
Когато агентът за записване се инициализира (редове 1-18), в дневника се записва различна информация за системата.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
Ред 19 посочва броя на шлюзовете Edge Gateway, намерени във файла gateways.xml за работа в директен режим.
19 | |
Ред 20 показва проблем при зареждането на ключове в несъществуваща директория. Това е стара функция, която не влияе на цялостната работа на агента. Следователно този запис за грешка в дневника може да бъде пренебрегнат.
20 | |
Ред 21 посочва действието по копиране на изпълнимия файл CareInit.exe в System32, за да се покрият случаите, в които RDP приложение с агент се стартира от компютър с macOS или Ubuntu.
В този случай при свързването към сървъра се заявява изпълнение на CareInit.exe като програма при стартиране.
21 | |
Свързване на HTML5 RDP или RDP приложение с агент (редове 22-39)
Когато бъде открита нова RDP сесия, в дневника се записват следните редове, които показват откриването на нова RDP сесия и записват потребителското име на влезлия потребител:
22 23 24 25 | |
В горните редове от дневника потребителят cyberelements_user е този, който се е свързал чрез RDP.
При стартиране на HTML5 RDP или RDP приложение с агент се създава специфичен виртуален RDP канал, за да се изпратят на агента за записване адресът за връзка с шлюза Edge Gateway и уникалната парола за свързване към услугата за записване на шлюза Edge Gateway.
Това показва две неща:
- Агентът за записване е открил, че това е RDP връзка, инициирана от CyberElements, така че не трябва да третира сесията като директен достъп.
- Агентът за записване е успял да извлече адреса на шлюза Edge Gateway, към който трябва да изпраща видеозаписите и събитията.
Тази информация съответства на редове 27-29, където в примера агентът за записване е извлякъл адреса за връзка на шлюза Edge Gateway (my-edge-gateway.domain.local) и еднократна парола (K5efPBwVM2cIU0LaYQucZp0FV19nRIE5f5VYoBZz6EqlZOxNGM):
29 30 31 | |
След това идват редовете в дневника, свързани с прилагането на правилата за мрежово филтриране, които са описани подробно в друга информационна част по-надолу на страницата.
Един от редовете в дневника посочва кога агентът за записване инициира връзката с шлюза Edge Gateway и коя уникална парола използва, за да се удостовери.
35 | |
Накрая, когато потребителят инициира прекъсване на връзката, то се прихваща от агента за записване, за да се прекрати записването и да се премахнат евентуалните правила за мрежово филтриране. Това съответства на редове 36-39 от примерния файл с дневник:
36 37 38 39 | |
Свързване с директен RDP достъп (редове 40-61)
Когато бъде открита нова RDP сесия, в дневника се записват следните редове, които показват откриването на нова RDP сесия и записват потребителското име на влезлия потребител:
40 41 42 43 | |
В горните редове от дневника потребителят cyberelements_user е този, който се е свързал чрез RDP.
При директна RDP връзка специфичният виртуален RDP канал за стартиране на RDP или HTML5 RDP приложения с агент не се използва. Следователно агентът за записване заключава, че отворената сесия е сесия с директен достъп.
44 | |
Поради откриването на директен достъп агентът за записване записва в дневника различните потребителски групи на потребителя, който току-що се е свързал:
46 | |
Съвет
С тази информация можете да определите причините, поради които записването на директния достъп не се задейства: ако договорът за директен достъп не упълномощава нито една от групите на потребителя или ако посоченото име на домейн трябва да бъде краткото име (име netBIOS) или пълното име.
Агентът за записване посочва към кои шлюзове Edge Gateway ще може да се свърже, за да качи записа на сесията на потребителя.
За напомняне, това са шлюзовете Edge Gateway, които са част от файла gateways.xml, конфигуриран по време на конфигурирането на агента за записване.
47 | |
Следва клиентският сертификат, който агентът за записване използва, за да се удостовери пред услугата за записване.
По подразбиране агентът за записване ще търси сертификат, съдържащ името на RDP сървъра в своя CN, освен ако не е зададен ключът MachineName.
След това агентът за записване посочва избрания сертификат и информацията за сертифициращия орган, който го е генерирал.
48 49 50 51 | |
В горния пример агентът за записване е търсил сертификат, съдържащ my-rds-server, и е намерил такъв с CN my-rds-server.domain.local, издаден от сертифициращия орган SUB-CA.
След това идват редовете в дневника, свързани с прилагането на правилата за мрежово филтриране, които са описани подробно в друга информационна част по-надолу на страницата.
Един от редовете в дневника посочва кога агентът за записване инициира връзката с шлюза Edge Gateway и коя уникална парола използва, за да се удостовери.
57 | |
Накрая, когато потребителят инициира прекъсване на връзката, то се прихваща от агента за записване, за да се прекрати записването и да се премахнат евентуалните правила за мрежово филтриране. Това съответства на редове 58-61 от примерния файл с дневник:
58 59 60 61 | |
Прилагане на правилата за мрежово филтриране (редове 31 и 53-56)
За всяка сесия, която открие, агентът за записване определя дали е необходимо да се приложат правила за мрежово филтриране към сесията на потребителя.
Ако не е необходимо да се прилагат правила за мрежово филтриране, агентът за записване ще посочи Filter not enabled.
31 | |
Ако трябва да се приложат правила за мрежово филтриране, ще се появи съобщението Net filter enabled.
След този ред за активиране на филтъра се посочва всеки от приложените филтри, по един на ред:
53 54 55 56 | |
За напомняне, когато мрежовото филтриране е активирано, поведението по подразбиране е да се блокира целият TCP/UDP трафик. Следователно посочените филтри са единственият TCP/UDP трафик, допуснат за програмите, изпълнявани в контекста на потребителя.
В горния пример връзките към TCP 10.10.1.42:443 и UDP 10.10.20.1:53 са разрешени. Освен тези два потока, допуснати от администратора, е отворен и потокът за връзка към услугата за записване, за да може записът на сесията да бъде изпратен обратно от програмата, която отговаря за това.
Съвет
Ако за потребителя не са допуснати никакви потоци, ще бъдат показани само редовете, които показват, че филтрирането е активно и че процесът на записване може да се свърже с услугата за записване на шлюза Edge Gateway.
Неуспешно свързване с услугата за записване
Няколко проблема могат да направят агента за записване неспособен да се свърже с услугата за записване на шлюз Edge Gateway.
Първият е блокиране на мрежовия поток. В този случай, когато агентът се опита да се свърже с услугата за записване, той записва в дневника редове, подобни на тези:
1 2 3 4 | |
В този пример ред 1 показва, че потокът не е могъл да бъде иницииран, а ред 3 посочва съответния шлюз Edge Gateway и неуспеха при свързването (обърнете внимание и на числото 242 в края на ред 3 за този тип проблем).
Вторият проблем, който може да възникне, е невъзможността на агента за записване, а следователно и на RDP сървъра, да преобразува името на шлюза Edge Gateway:
1 2 3 | |
В този пример ред 1 потвърждава проблема с DNS преобразуването на името на шлюза Edge Gateway.
Вторият ред посочва неуспеха при свързването и името на шлюза Edge Gateway. Обърнете внимание, че редът завършва с числото 232, когато DNS преобразуването е неуспешно.
Третият проблем, който може да възникне, е свързване към услуга, която не е услуга за записване, например уеб сървър, който слуша на порт 8443.
В този случай в дневника се получават следните редове:
1 2 3 | |
Ред 1 показва грешка в обменените данни, ред 2 потвърждава проблема с връзката и посочва грешка 140 в края на реда.
Нито един договор за директен достъп не позволява задействане на записването на директната сесия.
При директен достъп не всички потребители задължително трябва да бъдат записвани. В такъв случай в дневника се получават следните редове:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Получените редове започват като при всички директни сесии, прихванати от агента за записване. След като обаче връзката с услугата за записване на шлюза Edge Gateway бъде установена, тя връща на агента за записване информация, че свързаният потребител не подлежи на записване.
Следователно агентът за записване посочва, че не е необходимо сесията на потребителя да се записва (ред 14 от горния пример).
Ред 7 изброява всички групи, извлечени от агента за записване за свързания потребител.
Тази информация ви позволява да определите причините, поради които записването на директния достъп не се задейства: ако договорът за директен достъп не упълномощава нито една от групите на потребителя или ако посоченото име на домейн трябва да бъде краткото име (име netBIOS) или пълното име.



