Authentication & central access control: Setting up identities in a way that supports operations and auditing
When companies talk about “security,” the conversation quickly turns to firewalls, EDR, or patch cycles. In practice, however, something more fundamental often determines the outcome: Who is allowed to do what – and how reliably can this be enforced and verified across all systems? This is precisely where central authentication becomes a stable foundation. It reduces the proliferation of local accounts, makes permissions traceable, and creates a common language between operations, security, and specialist departments.
The pressure comes not only from technology, but also from framework conditions: Programs related to NIS2, industry-specific requirements, and established standards such as ISO/IEC 27001 or BSI-oriented security concepts increase the expectation for consistent access controls and auditable processes. At the same time, everyday life is shifting toward hybrid: classic servers, container platforms, CI/CD, and SaaS – everything is intertwined. A robust identity and rights basis ensures that this landscape remains manageable without treating each platform as a special case.
Why identity is more than just “login” today
Central authentication initially seems like an infrastructure issue—until you see the effects in operation. Without consistent identities, friction losses arise: tickets due to “missing rights,” shadow accounts for deployments, unclear responsibilities for admin access, and exceptions in audits that are difficult to explain. With a unified domain (e.g., LDAP/Kerberos plus clean Linux integration), permissions become more predictable, changes more reproducible, and access more justifiable.
Currently, this is intensifying in two directions. First, “identity as perimeter” has long been a reality: many attacks use compromised accounts, tokens, or poorly maintained service identities—not spectacular exploits at the edge. Second, expectations for verifiability are rising: In many environments, there are increasing questions about how privileged access is secured (MFA, roles, break glass), how changes are versioned, and what regular reviews look like – not just whether there is “a policy somewhere.”
Operating model & ownership
Who really operates the domain – including DNS, certificates, backup/restore, monitoring, and change process? In many organizations, identity fails not because of technology, but because of unclear ownership between the platform team, security, and workplace. Vendor or provider issues also play a role here: cloud IdP, on-prem domain, or hybrid – depending on skill and lifecycle realities, the “simplest” setup can become the most expensive in the long run.
Update & Security Capability
How is privileged access secured (MFA, bastion, JIT/JEA approaches, SSH-CA, break-glass with audit trail)? How are keytabs, certificates, passwords/tokens rotated? At a time when ransomware patterns often scale across identities, it’s not the most beautiful architecture drawing that counts, but whether policies work under pressure: incidents, team changes, migration, time pressure for patches.
Integration, data & lifecycle
Which systems need to be connected – Linux, web apps, file services, Jenkins/Runner, wikis, remote gateways? And how clean is the database (attributes, groups, roles, naming conventions, POSIX mapping)? Lifecycle issues are central here: What happens during re-domaining, when two organizations merge, when switching from Samba AD (Active Directory) to AD (or vice versa), or when converting to platform operation? Good decisions take these transitions into account instead of ignoring them.
Trainings
Specific trainings and current topics can be found in the Comelio GmbH course catalog.
Whether in-house at your company, as a webinar, or as an open event – the formats are flexibly tailored to different requirements.
Typical misconceptions that make central authentication expensive
“LDAP is enough, then it’s done.”
LDAP is a directory, but not yet a security model. Without clear attributes, a group concept, a naming and ID strategy, and defined processes for join/offboarding, LDAP quickly becomes a new source of errors. In practice, operational discipline is key: clean schema/attribute usage, traceable group structures, documented exceptions.
“Kerberos SSO is only for Windows.”
Kerberos SSO is a strength factor, especially in heterogeneous environments: tickets instead of password sharing, SSO for services, and a clear basis for secure access (e.g., to CIFS/NFS, web front ends, or administrative access). With the current trend toward zero-trust approaches, Kerberos fits well conceptually when operated cleanly (DNS/SRV, time, keytabs, rotation).
“SSSD/Winbind is a detail that can be dealt with later.”
Linux integration is rarely “just configuration.” ID mapping, POSIX attributes, home directories, sudo rules, PAM policies, and caching strategies must all fit together—otherwise, you’ll end up with exactly the problems you want to avoid: inconsistent UID/GID, changing permissions after migrations, and errors that are difficult to reproduce under load.
“For automation, we’ll just use a shared account.”
CI/CD, IaC, and job runners in particular generate the largest identity footprint. Shared accounts, static SSH keys, or long-lived tokens are a classic – and now a red flag in many security programs (supply chain risks, token theft, lack of accountability). Better options are dedicated service identities, limited rights, short validity periods, and traceable rotation.
Initial consultation / project initiation
If you want to consolidate, migrate, or set up identity as an operating standard (hybrid, platform integration, CI/CD connection, file services, privileged access), a short initial consultation can clarify where the greatest risks and expenses lie – and which architecture and operational decisions have the most leverage.
Frequently asked questions about authentication
In this FAQ, you will find the topics that come up most frequently in consulting and training sessions. Each answer is kept short and refers to further content if necessary. Can’t find your question? We are happy to help you personally.
How do I deal with local accounts and legacy accesses in a sensible way?
Transitions work best with clear priorities: first consolidate privileged access, then standard users, then special cases. Legacy accounts should be limited in time and function, with traceable exceptions and regular reviews – so that “temporary” does not become permanent.
LDAP, Kerberos, and SSSD: What is the clean distribution of roles?
LDAP is the database for identities and attributes, Kerberos provides ticket-based SSO, and SSSD stably connects Linux systems with directory and authentication. The key is a combination of clean DNS/time, a consistent attribute strategy, and standardized client policies.
Windows AD or Samba AD – how should you decide?
The question is less ideological than operational: Existing Microsoft ecosystems often benefit from AD features and established processes; open-source-first environments can create a robust foundation with Samba AD – if DNS/SRV, replication, POSIX attributes, and ID mapping are cleanly designed. It is important that the model remains migration-capable.
How can I pragmatically secure admin access without blocking operations?
Proven solutions include role-based sudo policies as code, MFA for critical entry points (e.g., bastion), dedicated admin identities, and a defined break-glass procedure with audit trail. The focus is on ensuring that the model remains practicable even under incident pressure.