ня з ідентифікатором 10001, яке було визначено під час настройки, але при поточному сеансі роботи це ж вікно має ідентифікатор, наприклад, 95262.
Рис.2. Майстер визначити установки програми і вікна аутентифікації
Існують і інші труднощі на шляху автоматичної аутентифікації: використання спливаючих вікон (splash screen), що переміщаються кнопки, неактивність вікна і т.д.
Для вирішення нетривіальних завдань аутентифікації використовуються макроси - невелика підпрограма на внутрішньому мовою SecureLogin, яка описує параметри вікна і способи взаємодії з ним. Варто відзначити, що методи, описані вище, так само засновані на макросах: у першому випадку макроси збережені як опис зумовлених додатків, у другому - SecureLogin автоматично генерує макрос.
Рис.3. Облікові записи для докладання mail. Перегляд через налаштовувану панель управління SecureLogin
Мова створення макросів містить більше 70 команд, які дозволяють описати роботу SecureLogin з будь-яким додатком (його вікном), а також використовувати при автоматичній аутентифікації будь-які типи даних і різноманітні методи введення.
Для спрощення написання макросів може використовуватися утиліта, яка визначає всі параметри вікна аутентифікації (виконуваного файлу) і видає у вигляді «чернетки» в синтаксисі SecureLogin.
Макроси можуть використовуватися не тільки в тому випадку, коли автоматичні методи не можуть бути реалізовані, але й коли потрібно створити «складну» модель аутентифікації, побудовану на безлічі залежностей.
Наприклад, існує певна програма, яка виконує підключення до віддаленого серверу. У цьому випадку користувачеві необхідно вказати свій логін, пароль і вибрати з випадаючого меню сервер, до якого він підключається. Якщо для кожного сервера використовується своя вчена запис (логін-пароль), то необхідно використовувати підпрограму, яка буде підставляти пару логін-пароль відповідну вибраного сервера. Або, наприклад, існує деяка періодичність доступності серверів, в цьому випадку можливо реалізувати автоматичне підключення до доступного сервера в залежності від часу доби.
Отже, SecureLogin виявляє вікна аутентифікації і автоматично вводить необхідні значення. Бувають ситуації, коли в одному і тому ж додатку у одного і того ж користувача існує кілька облікових записів. Класичний приклад - безкоштовні поштові сервери. Ця ситуація так само передбачена: SecureLogin може містити для одного і того ж користувача кілька наборів ПДА для входячи в одне і теж додаток. У цьому випадку можливі два варіанти поведінки системи: може бути налаштована на використання вибраного облікового запису; пропонуватиме користувачеві вибрати, яку саме обліковий запис але хоче використовувати саме зараз.
Рис.4. Визначення основних параметрів SecurLogin для контейнера Users через MMC-консоль
. 2 Структура SecureLogin
Сучасні навіть невеликі компанії прагнуть створити IT-структуру таким чином, щоб будь-які системи, що входять до її складу, мали можливість централізованого уніфікованого керування. Одна з важливих особливостей SecureLogin - це якраз можливість централізованого управління.
Рис.5. Копіювання налаштувань виконаних для контейнера Users в Organization Unit.
Якщо компанія використовує доменної структури мережі (а це найбільш часто зустрічається ситуація), то SecureLogin може бути інтегрований в Active Directory (AD), як окремий випадок служби каталогів, сумісних з протоколом LDAP (Light Data Access Protocol ). З цією метою виконується розширення схеми AD, внесення додаткових атрибутів об'єктам «User». Варто відзначити, що такі зміни схвалені Microsoft і можуть бути застосовані до таких структурних елементів як «User», так і до «Organization Unit» будь-якого рівня вкладеності. Так само підтримується робота на рівні групової політики. Ці особливості дозволяють виконувати однотипні настройки SecureLogin для цілих подразде?? ений і відділів, а, при необхідності, деталізувати їх для окремих користувачів.
Управління SecureLogin в цьому випадку виконується за допомогою стандартних MMC-консолей. У цьому випадку кожен користувач при роботі з SecureLogin використовуватиме ті настройки, які були зроблені системним адміністратором, що виключає, по-перше: необхідність рядового користувача вникати в принципи роботи цієї системи, а по-друге: виключає можливість виконувати несанкціоновані дії.
Отже, за рахунок можливості централізованого управління системний адміністратор один раз виконує настройку SecureLogin для роботи з кожним використовуваним в компанії додатком. Далі адміністратор може перенести ці та ін...
