Securing 1C Web Client Access with External MFA via Nginx, Keycloak and Active Directory
A production deployment of 1C web publications required the addition of multi-factor authentication for browser users without disrupting existing integrations or changing the authentication mechanism inside the information base.
The original IIS server handled both employee access and automated exchanges, HTTP services, and third-party system calls. Adding interactive MFA directly on this shared endpoint risked breaking automated requests that expect static responses rather than redirects.
The chosen architecture introduces an external security layer consisting of Nginx acting as the public HTTPS entry point and reverse proxy, Keycloak providing centralized authentication and MFA policy enforcement, and oauth2-proxy managing OIDC interactions. A second IIS instance was deployed exclusively for user web clients, while the original IIS remained untouched for integration traffic limited by IP allow lists.
Keycloak is federated with corporate Active Directory over LDAPS. A dedicated realm and OIDC client are configured, with group membership claims used to restrict access to the 1C_Web_2FA group. TOTP is enforced as the second factor, and session lifetimes, re-authentication policies, and recovery procedures are defined centrally.
Users opening the public address are redirected through oauth2-proxy to Keycloak when no valid session exists. After successful AD login and TOTP verification, the request is forwarded to the new IIS publication. Native 1C authorization inside the database remains unchanged because 1C OpenID Authentication is not used.
Integrations continue to connect to the legacy IIS from permitted addresses. IP restrictions are applied at the site level, and service accounts retain their existing authentication methods. Direct internet exposure of the user-facing IIS is blocked by firewall rules so that MFA cannot be bypassed.
Employees can install the web publication as a standalone browser application, preserving familiar desktop shortcuts while still routing traffic through the MFA-protected gateway. Pre-launch checks include verification that the new publication is unreachable without passing through Nginx, that cookie and redirect handling works correctly, and that group-based access controls function as intended.
Related articles
Avanpost Unveils DAG System for Sensitive File Discovery and Excessive Access Rights Management
Avanpost has launched its new DAG solution designed to control access to unstructured data across file servers, cloud environments, and corporate knowledge bases. The system scans file contents to identify confidential information, maps actual user permissions, and highlights policy violations that official regulations often overlook. Built-in workflow automation routes access review requests to data owners, collects approvals, assigns remediation tasks to IT teams, and verifies changes through follow-up scans. DAG integrates with existing IdM/IAM platforms to factor in employee roles and employment status, automatically triggering access reviews during job changes or terminations. The platform also forwards detected violations to SIEM and SOAR systems for coordinated response and supports both high-load enterprise deployments and simpler mid-market installations. Customers can request on-site pilots to evaluate the solution against their current infrastructure.
Why Complex Password Policies Fail to Protect Companies: Practical Account Security Guidance
Many organizations implement strict password rules requiring at least eight characters with numbers, uppercase letters, and special symbols, plus mandatory changes every 30 days. Employees respond by creating predictable variations such as Company2026!, Company2026@, and Company2026#, which offer little real protection against phishing or credential stuffing. The core issue lies in poor visibility into all accounts across Active Directory, VPN, cloud services, databases, and contractor access rather than password length alone. Effective security begins with full inventory of every account, classification into user, privileged, service, and external types, and clear ownership assignment. Privileged accounts require separate credentials, MFA, minimal rights, and activity logging, while service accounts must avoid hardcoded secrets in configuration files or source code. Password managers must enforce client-side encryption so that even compromised administrator accounts cannot access stored secrets. MFA deployment should prioritize high-risk entry points such as VPN, email, and backup systems, and access revocation must integrate with HR processes to prevent former employees or contractors from retaining credentials.
Wireshark Wi-Fi Traffic Analysis: Diagnosing Connectivity Failures in 802.11 Networks
Wireshark captures help distinguish between radio-layer issues, DHCP failures, and application-layer problems when a device connects to Wi-Fi but cannot load pages. The guide explains how to select the right capture point—client, monitor-mode adapter, or wired side of the access point—and why ordinary Ethernet headers often hide critical 802.11 management and control frames. Detailed sections cover CSMA/CA contention, frame types (Management, Control, Data), EAPOL-Key exchanges for WPA2-Personal, and the limitations of retry flags as loss indicators. Practical Linux commands using iw, dumpcap, and NetworkManager demonstrate how to enable monitor mode on channel 6 HT20 and record a two-minute trace. Filters for wlan.addr, eapol, and wlan.fc.retry allow analysts to isolate association failures, key-handshake problems, or DHCP delays. The article also addresses decryption of WPA2 traffic with a known passphrase and warns that Wireshark cannot replace a spectrum analyzer for detecting non-Wi-Fi interference.
15-Year-Old Developer Restores Social Network After Beget VPS Data Wipe in Cyber Attack
A 15-year-old Russian developer recovered his social network Agora within three hours after hosting provider Beget confirmed that a cyber attack had wiped his VPS, including binary backups. The recovery relied on offsite encrypted PostgreSQL dumps created just one day earlier using pg_dump and GPG, an escrow key for end-to-end encrypted messages, and pre-written migration scripts stored in a repository. The master encryption key stored only in the server environment was lost, rendering old private keys unusable and forcing a full re-encryption of 1218 messages via the escrow mechanism. Additional issues included broken authentication in existing Android builds, dead push notification subscriptions, and a failed monitoring runner hosted on the destroyed server. The incident highlighted the risks of single-provider architecture and insufficient offline key storage while demonstrating effective disaster recovery practices for a self-hosted Supabase stack.