Сеть подлинность не проверена: администрирование — Почему пропадает доменная сеть на одном компьютере с 20.00 до 8.00 и пишет «подлинность не проверена»?

Active Directory без проблем | Windows IT Pro/RE

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

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

Трудности с оборудованием

В общем, все домены AD весьма устойчивы к аппаратным неполадкам, которые приводят к отказу одного контроллера домена (DC). Конечно, это утверждение верно, только если в каждом домене развернуто более одного DC и выполняется постоянный мониторинг репликации изменений между контроллерами доменов. Таким образом, если один DC по какой-то причине выходит из строя, клиенты, проходящие проверку подлинности в домене, найдут в сети другой DC через DNS. При нормальной работе проблем не возникает, даже если контроллеры домена с какой-либо специализированной ролью Flexible Single-Master Operation (FSMO) выходят из строя на несколько часов или даже дней. Для нормальной работы AD не требуется, чтобы все контроллеры домена FSMO были доступны в любое время. Очевидно, необязательно обновлять схему или в массовом порядке создавать новые объекты в домене при отказе конкретных контроллеров домена FSMO. Но обычные операции, такие как изменение пользователями паролей или добавление администратором нового объекта в домен, будут выполняться по-прежнему. Это одно из главных достоинств AD и модели репликации с несколькими владельцами.

Но иногда причиной проблемы является не аппаратный отказ DC. Порой неполадки начинаются лишь после ремонта оборудования и перезагрузки DC — особенно если DC является эмулятором основного контроллера домена (PDC). По умолчанию все DC в домене AD синхронизируют время с эмулятором PDC соответствующего домена. Компьютеры и серверы в домене синхронизируют время с контроллером домена, используемым ими для проверки подлинности (обычно это DC в их сайте AD). Для проверки подлинности Kerberos все клиенты и контроллеры домена должны быть синхронизированы. Клиенты и серверы Windows 2000 Server и более поздних версий в домене AD используют Kerberos по умолчанию. В случае слишком большой разницы во времени между клиентом и сервером, на котором расположен нужный ресурс, такой как общая папка, проверка подлинности на сервере ресурса завершается неудачей. По умолчанию приемлемое рассогласование по времени в лесу AD — пять минут. Поэтому, даже если пользователь или компьютер успешно проходит проверку подлинности в домене, попытка доступа к серверу может завершиться неудачей из-за разницы во времени.

Какое отношение это имеет к аппаратному отказу DC в домене, возможно, даже основного DC? Очень простое: если в процессе ремонта оборудования была заменена системная плата сервера, обычно заменяется и встроенный в нее таймер. Маловероятно, чтобы время системного таймера новой платы совпадало со временем остального леса AD. Если после этого просто перезагрузить PDC, когда он подключен к сети, то другие контроллеры домена синхронизируют время с PDC, обнаружив, что он вновь присутствует в сети. В результате может появиться рассогласование времени на различных компьютерах, недопустимое для Kerberos. Хотя PDC может быть настроен на репликацию с внешним источником времени, в сеть внесена временная ошибка, которая вызовет неполадки, например невозможность серверов Microsoft Exchange Server использовать глобальные каталоги (GC) в своих сайтах для преобразований LDAP или пользователям не удастся получить доступ к общим каталогам. Может оказаться, что положение не нормализуется в течение нескольких часов или дней и даже потребуется ручное вмешательство.

Решение здесь простое: если нужно заменить системную плату DC, особенно вышедшего из строя DC, на котором размещена роль FSMO эмулятора PDC, удалите сетевой кабель перед перезагрузкой DC. После успешной перезагрузки DC (для которой может потребоваться больше времени, чем обычно, так как DC не сможет найти другие контроллеры домена для репликации), необходимо зарегистрироваться локально и установить время на DC. Затем можно вновь подключить сетевой кабель. Другой вариант: если PDC отвечает, можно временно перенести роль PDC на другой контроллер домена и выполнить обратный перенос после замены системной платы. Эти методы предотвращают проблемы временной синхронизации, которые в свою очередь нарушают процесс проверки подлинности в сети.

Проверка подлинности между лесами

Большинство администраторов AD смутно представляют, как клиенты используют DNS для обнаружения контроллеров домена в собственном лесу или домена в своей сети. Поэтому, прежде чем рассмотреть процесс между различными лесами AD и сетями, познакомимся с процедурой обнаружения DC внутри домена AD.

Клиент Windows 2000 или более поздней версии, который никогда ранее не проходил проверку подлинности в домене AD, направляет запрос DNS, чтобы получить сведения о любом DC, ответственном за собственный домен. При этом клиент запрашивает с сервера DNS список всех контроллеров домена, которые зарегистрировали типовую запись локатора DC (которая по умолчанию включает все контроллеры домена в домене AD). Чтобы извлечь эти записи, клиент сначала запрашивает типовые записи службы LDAP в зоне _msdcs иерархии DNS. Для домена AD с именем MyCompany.net типовые записи находятся в следующей иерархии DNS: _ldap._tcp.dc._msdcs.MyCompany.net.

Затем клиент устанавливает контакт с несколькими контроллерами домена из списка, полученного с сервера DNS, оповещает их о необходимости пройти проверку подлинности и ожидает ответа от первого DC. Но контроллеры домена достаточно интеллектуальны, чтобы оценить ситуацию, и поэтому проверяют IP-адрес, указанный клиентом в запросе. Они обнаруживают, что клиент присоединен к домену и сравнивают IP-адрес клиента с данными сайта и подсети, сохраненными в разделе конфигурации AD. С помощью этих данных контроллеры домена определяют сайт клиента и сообщают клиенту о необходимости подключиться к серверу DNS и сделать запрос о DC для проверки подлинности в собственном сайте. Затем клиент запрашивает нужную запись службы Kerberos.

Предположим, что клиент находится в офисе филиала домена AD MyCompany.net и имя сайта AD — BranchSite. Клиент запрашивает DNS о записях службы Kerberos, зарегистрированных для данного сайта. Эти записи находятся в следующей иерархии DNS: _kerberos._tcp .BranchSite._sites.dc._msdcs.MyCompany.net. На экране 1 также показана иерархия в оснастке DNS консоли управления Microsoft Management Console (MMC).

Затем сервер DNS возвращает сведения только о контроллерах домена, ответственных за сайт клиента, а клиент, в свою очередь, обращается к ним для проверки подлинности в домене. К счастью, клиент хранит в реестре информацию о последнем сайте AD, к которому он принадлежал, и сразу использует эту информацию в следующий раз при необходимости обнаружить DC. Имя сайта AD, записанное клиентом, находится в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNetlogonParameters DynamicSiteName.

Даже после того, как пользователь пройдет проверку в собственном домене, требуется сделать несколько дополнительных шагов, чтобы обеспечить доступ к ресурсам через границы доменов в лесу со многими доменами. Часто процесс обнаружения DC повторяется при обращении пользователя к ресурсам в другом домене леса. Хотя все домены в лесу доверяют друг другу, билет Kerberos на право получения билетов Ticket Granting Ticket (TGT), извлеченный клиентом из собственного DC при регистрации, действителен только для запроса билета службы, который, в свою очередь, предоставляет доступ к ресурсам в собственном домене клиента. Когда пользователь обращается к ресурсу в другом домене того же леса (например, к серверу файлов), клиент вновь сначала запрашивает DNS, чтобы найти DC домена файл-сервера и запросить билет TGT, действительный в этом домене. Удобно, что клиент немедленно находит нужный DC. Поскольку клиенту известно, в каком сайте он находится, он использует запрос DNS для конкретного сайта (аналогичный описанному выше) для поиска DC другого домена.

Одна из причин высокой эффективности этого процесса в лесу без обращений к типовым записям локатора DC другого домена заключается в том, что все домены одного леса реплицируют и используют один раздел конфигурации AD. В этом разделе также содержится информация о сайте и подсети, поэтому контроллеры из любых доменов леса правильно регистрируют записи локатора для соответствующих сайтов AD. Если сайт AD не располагает контроллером домена или не имеет DC для каждого домена леса, то механизм AutoSiteCoverage гарантирует, что ближайший DC зарегистрирует запись локатора в DNS. То есть в пределах своего леса клиент всегда может найти DC для конкретного сайта в любом домене лесе. Клиенту не приходится использовать типовые записи локатора DC, которые могут направить клиента для проверки подлинности на контроллер домена в другом полушарии. Но следует помнить, что процесс подразумевает доступность DC конкретного сайта; в противном случае клиент использует типовые записи локатора DC, что может привести к замедлению проверки подлинности и обработки объектов групповой политики (GPO).

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

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

Аналогично описанному процессу обнаружения DC между доменами, при обращении к ресурсу в доверенном лесе клиент запрашивает серверы DNS доверенного леса о подходящих контроллерах домена для проверки подлинности. Важно уяснить, что клиент вновь запрашивает в DNS записи службы Kerberos для конкретного сайта. Для этого клиент объединяет имя сайта из собственного домена MyCompany.net с именем домена доверенного леса OtherCompany.net и таким образом запрашивает следующую иерархию DNS: _kerberos._tcp.BranchSite._sites.dc._ msdcs.OtherCompany.net. Если такого сайта AD не существует в доверенном лесе (весьма вероятно для леса, спроектированного другой группой разработчиков), то запрос DNS заканчивается неудачей и клиент должен запросить типовые записи локатора DC. Затем подлинность клиента может быть проверена контроллерами домена доверенного леса. Этот способ явно не идеален и замедляет доступ к данным и приложениям между лесами.

Чтобы предотвратить эту проблему, достаточно создать в обоих лесах сайты AD с одинаковыми именами. Эти новые сайты можно рассматривать как «теневые» сайты доверенного леса. Нет необходимости добавлять к этим сайтам новые IP-подсети, и «теневые» сайты могут не содержать настоящих контроллеров домена. Создайте выделенное соединение сайта между каждым «теневым сайтом для MyCompany» и ближайшим «настоящим сайтом OtherCompany». Убедитесь, что к этому соединению сайта не присоединено никаких других сайтов, а сами теневые сайты не присоединены ни к каким другим связям сайтов. Такой подход гарантирует, что нужный DC леса OtherCompany.net добавит необходимые записи типа SRV к соответствующему теневому сайту через AutoSiteCoverage. Теневые сайты обеспечивают использование клиентами верных и ближайших контроллеров домена для проверки подлинности при обращении к ресурсам в доверенном лесу.

Удобная модель с наименьшими привилегиями

По мере того как компании предъявляют более строгие требования к информационной безопасности, администраторы AD начали использовать по крайней мере две учетные записи с различными правами: одну для регистрации на клиентских системах и выполнения повседневных задач (у этой учетной записи нет никаких административных прав в AD) и другую — с достаточными правами в AD для таких административных задач, как управление пользователями и группами. Работать с несколькими учетными записями неудобно даже при обращении к различным функциям операционной системы, например щелкая правой кнопкой мыши на оснастке Directory Users and Computers консоли MMC и выбирая Run для запуска команды из административной учетной записи. Хотя этот метод приемлем, досадно, что диалоговое окно Run, используемое для ввода административных учетных данных, никогда не помнит моей учетной записи для AD. Приходится вводить ее каждый раз, когда нужно расширить свои права.

Хорошее решение проблемы — развернуть централизованный сервер терминалов, на котором установлены все необходимые административные инструменты. Администраторы AD могут подключиться к серверу терминалов, пройти проверку подлинности с административной учетной записью и выполнить необходимые административные задачи в сеансе сервера терминалов. Нет необходимости использовать Run as, и можно даже разместить на настольном компьютере файлы RDP с нужным именем учетной записи. Конечно, не следует хранить пароль административной учетной записи в RDP-файлах. С помощью центрального сервера терминалов администраторы могут подключаться и выполнять свои обязанности с любого клиента — пакет инструментов Windows Server Administration Tools Pack (adminpak.msi) не обязательно устанавливать локально на клиенте. Однако инфраструктура многих предприятий слишком мала, чтобы устанавливать сервер терминалов исключительно для административных целей; могут существовать и другие причины для запуска инструментов управления AD с локального компьютера.

Другая возможность избежать монотонного щелканья правой кнопкой мыши на значках и ввода учетных данных — создать собственный ярлык для прямого запуска утилиты Runas, что позволит полностью задействовать параметры как командной строки, так и оснасток. Если учетные записи администратора отличаются от обычной учетной записи пользователя явным префиксом, то процесс управления ярлыками для нескольких пользователей можно упростить с помощью таких простых приемов, как расширение переменных среды USERNAME.

Например, мою обычную учетную запись пользователя (непривилегированную) можно назвать GUIDOG, а административную учетную запись — ADM.GUIDOG. Чтобы несколько администраторов могли использовать один ярлык на разных компьютерах, необходимо развернуть различные переменные среды в созданном ярлыке, для чего следует поместить соответствующую переменную среды между двумя символами процентов. Ниже приведен образец команды для ярлыка, который используется для запуска оснастки Active Directory Users and Computers с административной учетной записью, и запроса, привязанного к конкретному DC в моем домене:

%windir%system32 unas /env /
   user:%userdomain%adm.%username%
   «mmc %windir%system32dsa.msc /
   server=w2k8core01»

При создании ярлыка для этой команды можно создать предупреждение и напомнить самому себе, что выполняется переход на учетную запись с расширенными правами, применяя для этой цели цветные обозначения в самом ярлыке; в командной строке можно настроить цвета фона и шрифта ярлыка. На экране 2 показано окно, которое выводится при двойном щелчке на ярлыке пользователя GUIDOG. Красный цвет фона командной строки предупреждает, что готовится расширение прав. Поскольку команда Run as в ярлыке соответственно расширена %userdomain% ADM.%username%, мне более не приходится вводить имя учетной записи. Вместо этого появляется приглашение для ввода пароля учетной записи CORPADM.GUIDOG.

Ярлыки Windows являются настоящими файлами (с расширением .lnk), поэтому их можно скопировать в соответствующий общий раздел, доступный любому администратору леса AD. И если другой пользователь, например JOER, также имеет административную учетную запись с тем же соглашением об именовании, он может использовать такой же ярлык для запуска оснастки Active Directory Users and Computers и пройдет проверку подлинности как CORPADM.JOER.

64-разрядные версии Windows

В настоящее время наблюдается мощная тенденция перехода к 64-разрядным версиям Windows, особенно для приложений, которые выигрывают от расширенного пространства памяти 64-разрядной операционной системы. AD — одно из таких приложений. Если база данных AD не умещается в рамках, налагаемых на память 32-разрядными версиями Windows Server (см. таблицу), то перевод контроллеров домена в 64-разрядную среду Windows на оборудовании с достаточной физической памятью существенно увеличивает производительность AD, а также производительность зависимых от AD прикладных программ (например, Exchange).

В данной статье не обсуждается подробно, при каких условиях выгодно применять 64-разрядную версию Windows на контроллерах домена. Как правило, при объединении 32- и 64-разрядных DC в лесу AD (например, Windows Server 2003 x64) проблем не возникает. Для 64-разрядной среды не требуется специальных расширений схемы, а репликация между 32- и 64-разрядными контроллерами домена проходит успешно. Конечно, необходимы подходящие версии драйверов, антивирусные программы и агенты мониторинга, совместимые с 64-разрядной Windows. Правда, могут перестать функционировать некоторые инструменты управления Microsoft для AD. Самые важные из них — инструмент AD Replication Monitor (Replmon), консоль управления групповой политикой Group Policy Management Console (GPMC) и сервер экспорта паролей Password Export Server (PES) инструмента миграции Active Directory Migration Tool (ADMT). Большинство 32-разрядных приложений работает без проблем с 64-разрядной операционной системой Windows благодаря 64-разрядному режиму совместимости Windows-on-Windows (WoW64). Replmon, GPMC и ADMT PES — исключения из этого правила, так как у них есть другие зависимости, которые нельзя обеспечить с помощью WoW64. Replmon и GPMC безупречно функционируют на 32-разрядном сервере, члене домена и, таким образом, могут быть задействованы в 64-разрядном лесе AD и дистанционно подключаться к 64-разрядным контроллерам домена. ADMT PES необходимо установить на DC, поэтому нужно выделить 32-разрядный DC для этой службы или дождаться следующей версии ADMT, выпустить которую планируется вместе с Windows Server 2008. В ее состав войдет 64-разрядная служба PES.

Предупрежден —значит вооружен

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

Гвидо Грилленмейер ([email protected] ) — главный специалист по технологиям в подразделении Advanced Technology Group компании Hewlett-Packard. MVP по Microsoft Directory Services и Microsoft Certified Architect

SC пможет восстановить сервер

Как компьютерному консультанту мне часто приходится встречаться с системными администраторами, попавшими в затруднительное положение из-за невозможности работать через графический интерфейс. Благодаря множеству хороших инструментов командной строки и обширной информации о них в таких изданиях, как Windows IT Pro, в распоряжении администраторов есть богатый набор методов для устранения неполадок

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

Потеря RPC-сервера

Во вторник было запланировано применение программных исправлений на серверах в центре обработки данных. Исправления удобнее применять через дистанционное соединение, поэтому примерно в 21.00 Фрэнк зарегистрировался в системе и применил исправления ко всем серверам, в том числе к контроллеру домена (DC) с ролью Global Catalog (GC).

После перезагрузки все серверы ответили на команду ping. Но при попытке посмотреть электронную почту Microsoft Office Outlook не смог найти сервер Exchange. Администратор попытался зарегистрироваться на DC, но получил сообщение о недоступности RPC-сервера: The system cannot log you on due to the following error: The RPC server is unavailable. Все средства графического интерфейса оказались неэффективными: получить доступ к роли GC не удавалось. Без этой роли на контроллере домена Active Directory функционирование Exchange невозможно.

Фрэнк пытался выяснить, что произошло с сервером, и вспомнил об оснастке консоли Microsoft Management Console (MMC), с помощью которой можно читать журналы другого сервера. Поэтому он зарегистрировался на сервере, члене домена, и попытался запустить оснастку, но так и не смог обратиться к DC. Фрэнк оказался на «острове» без возможности добраться до «материка» DC и не мог получить никакой информации из компьютера, чтобы решить проблему.

Пытаясь найти выход из положения, он ходил из угла в угол по комнате и споткнулся о сумку из-под ноутбука, словно выброшенную из океана на песок. Заглянув внутрь, он нашел номер Windows IT Pro. В растерянности он стал листать журнал.

Спасительный инструмент SC

Случайно ему попалась на глаза статья об инструменте командной строки, SC (sc.exe), который можно использовать для управления службами на локальном или удаленном компьютере. Это была статья «Универсальный диспетчер служб Service Controller» (Windows IT Pro/RE, март 2007 г.). Читая статью, Фрэнк понял, что этот инструмент и поможет ему выйти из затруднения.

Он вновь зарегистрировался на сервере, члене домена, и ввел команду SC в командном окне, чтобы определить синтаксис, который имел вид:

sc [command] [service name] …

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

sc 192.168.10.10 query

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

sc 192.168.10.10 query RPC

Команда вернула сообщение об ошибке: [SC] EnumQueryServices Status:OpenService FAILED 1060: The specified service does not exist as an installed service.

Из этого сообщения об ошибке Фрэнк сделал вывод, что команда SC не распознала отображаемое имя службы RPC (то есть RPC), поэтому он повторил команду со служебным именем RPC, rpcss. На этот раз результаты команды показали, что служба RPC функционирует, хотя ошибка при входе указывала, что служба недоступна. Фрэнк был в недоумении. Продолжая изучать результаты запроса, он заметил параметр State. Значение State, равное 4, свидетельствует о том, что служба функционирует.

Определение причин

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

У него не было доступа к services.msc, чтобы запустить или остановить службу Netlogon, но был инструмент SC. Поэтому Фрэнк остановил службу Netlogon с помощью команды

sc 192.168.10.10 stop netlogon

Затем он направил запрос, чтобы посмотреть результат выполнения предыдущей команды:

sc 192.168.10.10 query netlogon

Теперь значение State для Netlogon было 2, то есть служба не работала. Затем он запустил Netlogon с помощью команды

sc 192.168.10.10 start netlogon

Чтобы узнать результаты этой команды, он вновь направил запрос к Netlogon и увидел, что служба функционирует! Затем Фрэнк запустил службу на всех компьютерах сети с помощью инструмента командной строки SC.

Теперь он мог зарегистрироваться на DC; все службы сервера GC были активны и электронная почта работала. Фрэнку удалось выбраться с «острова Командной строки» и подняться на борт корабля «Графический интерфейс». Вывод: иметь под рукой правильно подобранный инструментарий — все равно что плавать в море со спасательным жилетом. Он может не потребоваться, но очень пригодится, если налетит шторм.

Курт Спанбург ([email protected] ) — консультант, работает в компании Solutions Consulting Group, имеет звание MVP по Microsoft Dynamics CRM

Включение HTTPS на вашем веб-сервере—Portal for ArcGIS

Для обеспечения сетевой связи между ArcGIS Web Adaptor и ArcGIS Enterprise используйте протокол HTTPS.

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

Использование порта HTTPS по умолчанию 443 подходит для подавляющего большинства развертываний. В редких случаях, экземпляр ArcGIS Web Adaptor не может использовать порт 443 на своем веб-сервере из-за ограничений, принятых в организации. Если это применимо к вашей организации, см. Использование портов, не предлагаемых по умолчанию, для ArcGIS Web Adaptor портала, где описываются дополнительные шаги по настройке.

Вы должны получить сертификат сервера и привязать его к веб-сайту, на котором размещается ArcGIS Web Adaptor. Каждый веб-сервер имеет собственную процедуру загрузки сертификата и его привязки к веб-сайту.

Также убедитесь, что ваш веб-сервер настроен на игнорирование клиентских сертификатов для правильного доступа к защищенным сервисам через HTTPS.

Создание или получение сертификата сервера

Для создания HTTPS-соединения между ArcGIS Web Adaptor и организацией веб-серверу требуется сертификат сервера. Сертификат – это цифровой файл, содержащий информацию об удостоверении веб-сервера. Он также содержит метод шифрования, который используется при создании защищенного канала между веб-сервером и организацией. Сертификат должен создаваться владельцем веб-сайта и иметь цифровую подпись. Существует три типа сертификатов – подписанные центром сертификации (ЦС), домена и самозаверенный – которые описываются ниже.

Сертификаты, подписанные центром сертификации (ЦС)

Сертификаты, подписанные независимым центром сертификации (ЦС), гарантируют клиентам, что идентичность веб-сайта была проверена. Центр сертификации обычно является доверенной третьей стороной, которая может подтвердить подлинность веб-сайта. Если веб-сайт заслуживает доверия, центр сертификации добавляет свою собственную цифровую подпись к самозаверенному сертификату этого веб-сайта. Это говорит веб-клиентам, что идентичность веб-сайта проверена.

Используйте сертификаты для производственных систем, подписанные ЦС, особенно если к вашей организации ArcGIS Enterprise будут иметь доступ пользователи за пределами вашей организации.

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

Сертификаты домена

Если организация расположена за вашим брандмауэром, и вы не можете использовать сертификат, подписанный ЦС, используйте сертификат домена. Доменный сертификат – это внутренний сертификат, подписанный ЦС вашей организации. Использование сертификата домена помогает снизить стоимость выпуска сертификатов и упрощает развертывание сертификатов, поскольку сертификаты могут быть сгенерированы в вашей организации для доверительного внутреннего пользования.

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

Создание доменного сертификата и включение HTTPS

Для успешного завершения мастера настройки ArcGIS Enterprise требуется, чтобы HTTPS был включен на веб-сервере на компьютере, на котором установлено базовое развертывание.

Если HTTPS не включен, мастер настройки не завершит работу, и вы получите следующее сообщение об ошибке:

URL-адрес веб-адаптера https://mymachine.mydomain.com/server не доступен. Убедитесь, что для веб-сервера включена поддержка HTTPS. Инструкции по включению HTTPS см. в разделе справки Введение в ArcGIS Enterprise > ArcGIS Enterprise Builder > Планирование базового развертывания.

В большинстве случаев ваш IT-администратор даст вам сертификаты и привяжет их к HTTPS порту 443.

В 2017 году Google Chrome начал работать только с доверенными сертификатами с параметром Subject Alternative Name (SAN), которые не может быть настроен, если сертификат был создан в приложении IIS Manager.

Если вы используете IIS, и вам необходимо создать сертификат домена, см. Создать сертификат домена, где можно воспользоваться скриптом для запуска на вашем компьютере, который создаст соответствующий сертификат и встроит его в HTTPS порт 443.

Самозаверенные сертификаты

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

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

При первоначальной настройке организации вы можете использовать самозаверенный сертификат для начального тестирования, чтобы проверить заданную конфигурацию. Однако если вы используете самозаверенный сертификат, во время тестирования вы увидите следующее:

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

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

• Вы не сможете открыть интегрированный сервис во вьюере карт, добавить защищенный элемент сервиса в организацию, войти в ArcGIS Server Manager на интегрированном сервере или подключиться к организации из ArcGIS for Office.

  Чтобы разрешить вход из ArcGIS for Office, установите самозаверенный сертификат в хранилище сертификатов Доверенных корневых центров сертификации на компьютере с запущенным ArcGIS for Office.

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

Внимание:

Выше приведен частичный список проблем, которые могут возникнуть при использовании самозаверенного сертификата. Для полного тестирования и развертывания организации ArcGIS Enterprise рекомендуется использовать сертификат домена или сертификат, подписанный ЦС.

Привязка сертификата к веб-сайту

Вы должны привязать свой сертификат к хостингу веб-сайта ArcGIS Web Adaptor. Привязка означает процесс настройки сертификата для использования порта 443 на веб-сайте.

Скрипт, приведенный в статье Создать сертификат домена привяжет сертификат для вас.

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

1. Выберите сайт в дереве каталога и на панели Действия щелкните Связи.
   • Если порт 443 отсутствует в списке Связи, щелкните Добавить. В ниспадающем списке Тип выберите https. Оставьте порт 443.

   • Если порт 443 имеется в списке, выберите его и щелкните Редактировать.
2. В ниспадающем списке сертификата выберите имя вашего сертификата и щелкните OK.

Проверка вашего сайта

После получения или создания сертификата, привязанного к порту 443, настройте Web Adaptor для использования с порталом. Вы должны открыть страницу настройки ArcGIS Web Adaptor с использованием URL по протоколу HTTPS, например, https://webadaptorhost.domain.com/webadaptorname/webadaptor.

После настройки Web Adaptor проверьте правильность работы HTTPS, отправив HTTPS-запрос организации, например, https://webadaptorhost.domain.com/webadaptorname/home. Если вы проводите тестирование с самозаверенным сертификатом, отключите предупреждения браузера о небезопасном подключении. Обычно это делается путем добавления в браузер исключения, разрешающего работать с сайтом, имеющим самозаверенный сертификат.

Отзыв по этому разделу?

5 быстрых методов решения ошибки аутентификации WiFi в 2023 году

Вы сталкивались с подключением к сети WiFi на своем телефоне Android только для получения ошибки аутентификации WiFi даже с вашим именем пользователя и паролем? Это нормально, и это происходит, даже если вы уже подключались к этой сети Wi-Fi раньше. Эта проблема не обязательно серьезна, и в большинстве случаев ее можно легко решить. Давайте посмотрим, почему это происходит, когда вы пытаетесь подключиться, и как мы можем решить эту проблему.

Обязательно прочтите: 20 лучших анализаторов WiFi для Android

Почему возникает ошибка аутентификации WiFi?

Ошибка аутентификации WiFi возникает, когда ваш телефон Android не может успешно подключиться к сети WiFi, когда вы хотите подключиться, даже если вы используете правильный пароль или иногда, если вы находитесь в режиме полета. В обычных условиях ваш телефон автоматически подключится к беспроводной сети, если вы уже подключались к сети Wi-Fi раньше. Вы можете столкнуться с проблемами, если у вас нестабильный сигнал, который вы можете улучшить с помощью усилителей сигнала сотового телефона.

Если вы случайно включили режим полета в настройках сети, ваш телефон не будет подключаться ни к одной сети на ваших устройствах Android. Но иногда проблема аутентификации заключается не только в том, что ваш телефон находится в режиме полета. Ниже приведены некоторые из распространенных причин, по которым вы получаете ошибку аутентификации Wi-Fi:

• Последнее обновление устройства
• Неисправность маршрутизатора
• Нестабильное сетевое соединение
• Количество пользователей, которые могут использовать сеть WiFi, ограничено

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

Связанные :

Как решить проблемы с мобильной сетью Android

Как использовать старый телефон Android в качестве устройства WiFi

Почему мой Wi-Fi продолжает отключаться и включаться сам по себе?

4 способа исправить ошибку аутентификации WiFi

4 метода решения ошибки аутентификации WiFi

1. Забудьте о сети
2. Измените сетевые настройки с DHCP на статические
3. Перезапустите маршрутизатор
4. Сброс к заводским настройкам

Эти 4 простых метода помогут вам исправить ошибку аутентификации WiFi. Читайте дальше, чтобы узнать, как решить ошибку аутентификации WiFi с помощью пошагового руководства.

1. Забудьте о сети

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

Шаг 1. Перейдите к параметрам Wi-Fi в меню настроек

Нажмите Wi-Fi

Перейдите к Настройки на своем телефоне и найдите « Беспроводные сети ». Вместо этого на некоторых смартфонах указано « Connections ». Нажмите на это и перейдите к опции WiFi.

Шаг 2. Найдите сеть, с которой у вас возникли проблемы

Выберите сеть, о которой вы забудете

После того, как вы выберете параметр WiFi в настройках сети, вы увидите список ближайших сетей Wi-Fi, включая те, которые вы мы уже подключались к раньше. Нажмите на имя сети, с которой у вас проблемы с подключением.

Шаг 3. Нажмите «Забыть сеть».

Забыть сеть.

При выборе сети в настройках сети появится параметр « Забыть сеть ». Нажмите, чтобы сбросить настройки выбранной сети. После сброса попробуйте ввести пароль, подключившись к сети. Вас попросят ввести пароль аутентификации. Просто введите пароль и подключитесь.

Если этот шаг не устранил вашу ошибку аутентификации WiFi на Android, перейдите к следующему.

2. Измените беспроводную сеть с DHCP на статическую

Шаг 1. Перейдите к параметрам WiFi в настройках

Выберите сеть

Перейдите к настройкам WiFi на устройстве Android и найдите соединение, которое вы хотите изменить.

Шаг 2: Нажмите на сеть, к которой вы подключены

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

Шаг 3: Изменить сеть

Управление настройками сети

При нажатии на беспроводную сеть вы увидите параметр Изменить или Управление сетью . Коснитесь его.

Шаг 4. Измените сеть на «статическую»

Измените настройки IP на статическую

В настройках WiFi вы увидите параметр « Дополнительные настройки » на своем устройстве Android. Выберите этот вариант и найдите « Настройки IP ». Оттуда измените IP-адрес с DHCP на статический. Наконец, введите IP-адрес (тот, который указан на задней панели маршрутизатора) в поле. Сохраните настройки, затем снова подключитесь. Это исправляет ошибку аутентификации WiFi для большинства людей; если это исправление не работает для вас, попробуйте другие шаги.

3. Перезагрузите маршрутизатор

Перезагрузите маршрутизатор

Если первые 3 метода не исправили ошибку аутентификации WiFi, проблема может быть связана с самим маршрутизатором. Перезапуск маршрутизатора может помочь и восстановить подключение к Интернету. Существует 3 способа перезапустить маршрутизатор, в зависимости от типа используемого маршрутизатора. Они следующие:

Шаг 1: Отсоедините кабель питания

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

Шаг 2. Перезапустите с помощью кнопки питания или горячей перезагрузки

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

Шаг 3: Настройка разрешенных подключений

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

После перезагрузки маршрутизатора перезагрузите устройство и посмотрите, не возникнет ли ошибка аутентификации WiFi по-прежнему. Если ошибка по-прежнему

4. Сбросить заводские настройки

Если первые 3 метода не помогли или если ваш телефон страдает от других случайных ошибок, помимо ошибок аутентификации WiFi, возможно, у вашего телефона проблемы с программным обеспечением. Это происходит при установке обновления прошивки, пользовательского ПЗУ или неисправного приложения.

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

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

Шаг 1. Перейдите в раздел «Резервное копирование и сброс».0005 Резервное копирование и сброс

”опция. Коснитесь его, чтобы открыть.

Шаг 2. Включите автоматическое восстановление

Вы увидите параметр  Automatic Restore . Если он не включен, убедитесь, что вы его включили.

Шаг 3. Сброс заводских данных

Найдите параметр « Сброс заводских данных » и коснитесь его. Затем нажмите кнопку « Сбросить телефон », чтобы подтвердить действие. Процесс займет несколько минут. Это загрузит систему вашего телефона. Если проблема действительно связана с проблемами программного обеспечения, вы можете подключиться к сети.

Если у вашего телефона нет аппаратных проблем, это решит проблему с ошибкой аутентификации WiFi на вашем устройстве.

5. Переключение режима полета

Как и при устранении любых неполадок, вы должны начать с самых простых возможных решений и, если они не работают, переходить к более сложным решениям. Самое простое, что вы можете попробовать, — это перевести свой Android-телефон в режим полета, который отключает большую часть или все радиостанции на вашем устройстве. Это похоже на перезагрузку вашего Wi-Fi-радио.

Выполните следующие действия, чтобы перевести телефон Android в режим полета:

Шаг 1: Проведите вниз от верхней части телефона 

Шаг 2: Вы увидите значки быстрого доступа.

Шаг 3: В этих значках нажмите «Режим полета». (Значок будет иметь форму самолета.) 

Шаг 4: Подождите несколько секунд и коснитесь значка еще раз, чтобы отключить его. Проверьте свой Wi-Fi и посмотрите, правильно ли он теперь подключается.

Не удается подключиться к WiFi 5 ГГц?

Еще одна распространенная проблема, с которой сталкиваются пользователи, заключается в том, что они не могут подключиться к Wi-Fi 5 ГГц. Позвольте мне сказать вам, чтобы иметь возможность подключаться к полосе пропускания 5 ГГц, ваш телефон должен поддерживать ее в первую очередь.

Чтобы проверить это, нажмите и удерживайте значок WiFi на панели уведомлений или перейдите в «Настройки» > «Wi-Fi» > «Дополнительно» > «Полоса частот» и проверьте, какой диапазон включен — 2,4 ГГц, 5 ГГц или автоматический. Если ваш телефон не поддерживает 5 ГГц, он не будет отображаться в полосах частот. Чтобы включить частоту 5 ГГц, выберите полосу частот 5 ГГц.

Обратите внимание, что диапазон 2,4 ГГц обеспечивает связь на большом расстоянии, но скорость низкая, тогда как диапазон 5 ГГц обеспечивает более высокую скорость, но для более короткого диапазона.

Читайте также:

8 лучших приложений для определения уровня сигнала WiFi для Android

30+ способов решить проблемы с мобильной сетью Android дома

Топ-20 лучших 100% бесплатных VPN-приложений для Android значит ошибка аутентификации?

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

Как исправить ошибку аутентификации на Samsung Galaxy S3?

Сообщается, что у Galaxy S3 возникла проблема с ошибкой аутентификации. Вышеупомянутые методы обычно работают для исправления ошибки.

Как решить проблему аутентификации точки доступа?

Наиболее распространенным решением является изменение протокола безопасности, например, с WPA на WPA2. Вы также можете сбросить сеть вручную, нажав «Забыть сеть».

Как исправить ошибку аутентификации Samsung Galaxy S8 WiFi?

Снова зарегистрируйте сеть WiFi, перезагрузив устройство Samsung Galaxy S8. Чтобы сбросить настройки, выберите «Настройки» > «Общее управление» > «Сброс» > «Сбросить настройки сети» > «Сбросить настройки». Затем снова зарегистрируйте свою сеть WiFi и повторно введите пароль для подключения.

Почему возникает ошибка аутентификации на устройствах Samsung Galaxy?

В устройствах Samsung Galaxy аутентификация WiFi чаще всего происходит из-за неправильного пароля. Измените пароль сети Wi-Fi и повторите попытку подключения.

Если ошибка аутентификации WiFi сохраняется

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

Надеюсь, эта статья была вам полезна! Поделитесь своими комментариями и предложениями ниже !

Изображение ссылка на изображение

Предлагаемые чтения:

5 Лучшее приложение Wi-Fi для Android для постоянного подключения

Как исправить аутентификацию Facebook. Проблемы на Android

• Быстрое решение проблем с аутентификацией Wi-Fi на Android состоит в том, чтобы включать и выключать режим полета или «забывать» сеть Wi-Fi и повторно подключаться к ней.
• Иногда вы можете столкнуться с ошибкой аутентификации при попытке подключиться к Wi-Fi с помощью вашего устройства Android, даже если это сеть, которую вы использовали ранее, и ваш пароль правильный.
• Вот наиболее распространенные способы устранения проблем с аутентификацией Wi-Fi на устройстве Android.

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

Как исправить проблемы с аутентификацией Wi-Fi на Android

В следующий раз, когда у вас возникнет проблема с аутентификацией Wi-Fi, вот наиболее распространенные способы устранения неполадок и устранения ошибки.

Переключить режим полета

Как и при любом устранении неполадок, вы должны начать с самых простых возможных решений и, если они не работают, переходить к более сложным решениям. Самое простое, что вы можете попробовать, — это перевести свой Android-телефон в режим полета, который отключает большую часть или все радиостанции на вашем устройстве. Это похоже на перезагрузку вашего Wi-Fi-радио.

Для этого проведите вниз от верхней части телефона, чтобы увидеть значки быстрого доступа, и коснитесь «Режим полета». (Значок будет иметь форму самолета.) Подождите несколько секунд и коснитесь значка еще раз, чтобы выключить его. Проверьте свой Wi-Fi и посмотрите, правильно ли он теперь подключается.

Включайте и выключайте режим полета на панели быстрого доступа.

Дэйв Джонсон/Business Insider

Забыть и снова подключиться к сети Wi-Fi

Если настройки Wi-Fi для этой сети были повреждены, вы можете начать работу, «забыв» сеть, а затем повторно подключившись к ней. Прежде чем начать, вам нужно знать пароль Wi-Fi.

1. Запустите приложение «Настройки».

2. Перейдите к настройкам Wi-Fi. Где это найти, зависит от того, какой телефон Android и версию ОС вы используете, но обычно это можно найти в «Беспроводные сети» или «Подключения».

3. Коснитесь и удерживайте сеть Wi-Fi, к которой вы пытаетесь подключиться, или коснитесь значка настроек в виде шестеренки. Затем выберите «Забыть эту сеть».

Большинство проблем с аутентификацией можно решить, отключив сеть Wi-Fi, а затем снова подключившись к ней и снова введя пароль.

Дэйв Джонсон/Business Insider

4. Через некоторое время сеть появится в списке доступных сетей. Коснитесь его и введите пароль для повторного подключения.

Перезагрузите маршрутизатор Wi-Fi

Если вам не удалось подключиться к домашней сети Wi-Fi, у вас есть другой вариант: вы можете перезагрузить маршрутизатор. Просто отключите маршрутизатор и оставьте его без питания примерно на две минуты. Затем снова подключите его и проверьте соединение.

Изменить сеть с DHCP на статическую

Если вы по-прежнему не можете пройти аутентификацию, вы можете попробовать заставить свой Android-телефон использовать статический IP-адрес вместо динамического выбора его при подключении, который используется по умолчанию и встречается гораздо чаще.

1. Откройте настройки Wi-Fi в приложении «Настройки», как вы это делали, когда забыли о сети, нажмите и удерживайте сеть или выберите значок настроек.

2. Выберите «Изменить эту сеть» или «Дополнительно» в зависимости от вашего телефона Android и найдите «DHCP».

3. Нажмите «DHCP» и в раскрывающемся меню выберите «Статический».

Переключитесь с динамического на статический IP-адрес, чтобы устранить более неясные проблемы с аутентификацией.

Дэйв Джонсон/Business Insider

4. Нажмите «Сохранить».

Теперь, когда ваш телефон использует статический IP-адрес для подключения к сети Wi-Fi, попробуйте еще раз.

Сбросить настройки сети

Если ни один из этих вариантов не работает, у вас есть последний вариант: вы можете попробовать сбросить все настройки сети.

1. Запустите приложение «Настройки».

Если ничего не помогает, вы можете сбросить весь набор сетевых настроек, но вам нужно будет повторно подключиться к сетям Wi-Fi и заново выполнить сопряжение устройств Bluetooth.

Дэйв Джонсон/Business Insider

2 . В поле поиска в верхней части страницы настроек введите «Сброс». В результатах поиска найдите и коснитесь «Сбросить настройки сети». Это сотрет все ваши настройки Wi-Fi, сотовой связи и Bluetooth, поэтому вам нужно будет перенастроить эти сети.

3. Нажмите «Сбросить сеть».

• Почему мой Android сильно нагревается? 6 способов исправить перегрев телефона и как его предотвратить

• 5 простых способов освободить место на телефоне или планшете Android

• Почему мой Android не заряжается? 7 способов решить проблемы с зарядкой на вашем Android-устройстве

• Почему мой Android не звонит? 8 способов починить телефон, если он пропускает звонки

• Как забыть о сети Wi-Fi на устройстве Android и прекратить автоматическое подключение к определенным сетям

• Как стереть ваши личные данные с устройства Android, если вы планирую продать или подарить

Дэйв Джонсон

Внештатный писатель

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