Opens in a new tab

Why Active Directory Weaknesses Stay Open in Small Public-Sector Teams

  • Home
  • Blog
  • Why Active Directory Weaknesses Stay Open in Small Public-Sector Teams
Municipal server rack representing a 27-team Active Directory security cohort

Public-sector IT teams can address long-standing Active Directory and Windows Server weaknesses through structured peer learning, practical testing and clear ownership after a 12-week security cohort. A statewide audit initially produced reports of up to 150 pages, but concise priorities, scheduled work and local decision-making helped 27 municipal IT organizations make measurable progress.

The municipalities already recognized that they needed to improve server and directory security. The practical obstacle was figuring out how a small team could find enough time and energy to act on known weaknesses while handling many other responsibilities.

What limits Active Directory security in small teams?

Active Directory is an older technology that can carry technical, organizational and process debt, particularly where Microsoft technologies have been used for decades. Money can buy additional tools or licenses, but it cannot remove the workload facing a team with only one or two administrators.

The deeper constraint is focused motivation. Small teams may be working hard to address individual gaps without dedicating sustained attention to one defined security goal. Reports from a statewide audit added to that problem. Some were as long as 150 pages, which may contain useful findings while remaining difficult for a busy team to turn into a manageable action plan.

A concise plan of five to eight pages can improve focus, but it still requires time and energy. Cohort participation supplies both by giving administrators a fixed schedule, a shared objective and a group that is working on the same problem at a similar stage.

How did the municipal security cohort work?

The first municipal IT security cohort drew 27 municipal IT organizations, more than the planned 10 to 15 participants. The group was divided into morning and afternoon cohorts so the format could remain manageable.

The program lasted 12 weeks and followed a defined weekly rhythm. Participants attended a two-hour session each Wednesday, either in the morning or afternoon. They also completed asynchronous work through a shared platform and handled homework between sessions.

Each organization worked on its own environment while learning from the team, the facilitators and earlier participants. Shared knowledge, tools and templates helped municipalities solve their own problems in parallel. Measurements at the beginning and end of the program gave every group a clear view of its starting position, its remaining work and the progress made toward the common goal.

The schedule also created momentum. Near the end, participants could compare their current position with the point reached by an earlier cohort. In some cases, the expectation was that participants would complete 100 to 120 percent of the target they had set.

How can risky hardening settings be changed safely?

Changes to SMB signing, LDAP signing and Kerberos hardening can interrupt systems if they are applied without enough preparation. The cohort handled that risk in stages, beginning with basic logging and auditing so each organization could inspect its own infrastructure.

Those records showed which SMB versions were in use and whether LDAP signing was enabled. After the logging systems worked across the group, participants moved through other topics and returned to the audit records several weeks later to decide whether they could proceed.

Some organizations required individual support. With a cohort of 15, two or three participants might need one-on-one help to remain aligned with the rest of the group. The discussions covered possible failures, but each organization made its own decision about accepting residual risk.

How were production changes tested?

All changes were tested in a dedicated laboratory modeled on a simple municipal infrastructure. The test environment covered standard conditions as well as situations that could cause failures.

Rollback plans were prepared separately by each organization because the appropriate procedure depended on its local infrastructure. Participants received a common methodology and forum for reviewing the plans, but each municipality assessed and managed its own risk.

How can settings remain under control after the cohort?

Two elements helped participants continue the work. First, the cohort created a community that remained connected after the 12-week program ended. Participants could keep using the shared platform and exchange channels, although less frequently than during the weekly sessions.

Second, a single cohort cannot address every security problem in a municipality. A repeating program made up of successive cohorts can create a broader structure for improvement. Smaller learning cycles can fit inside a longer program, with each group addressing its remaining gaps before moving to another topic.

It also keeps ongoing work part of a continuing program rather than ending it after one settings change.

Why was the cohort divided into two groups?

The aim is to keep each group small enough for useful visibility and peer exchange, while retaining access to a broader community. The target size is 10 to 15 participants, compared with a classroom of 25 to 35 students where individual attention becomes harder to maintain.

With 27 applicants, two groups allowed every municipal IT organization to participate. The groups could share experiences and compare results. Work tested in the morning could be adapted in the afternoon, adding knowledge exchange without requiring a full connection between every participant.

What made the cohort approach effective?

The program combined a limited number of security priorities with repeated measurement, scheduled participation, lab testing and individual risk decisions. It also connected each organization with peers facing similar infrastructure and security work.

For small public-sector IT teams, the model addresses a practical capacity problem: a known weakness must become a defined task, an assigned schedule and a tested change before it can be closed. The 27-participant municipal program showed how that structure can be applied across many organizations while preserving local control.

FAQ

How many municipalities joined the Active Directory security cohort?

Twenty-seven municipal IT organizations joined the first municipal IT security cohort. The participants were divided into two groups because the target size for each cohort was 10 to 15 organizations.

How long did the municipal security cohort run?

The program ran for 12 weeks. It included a two-hour session each Wednesday, along with asynchronous work and assignments between sessions.

Which Active Directory security settings were addressed?

The cohort addressed SMB signing, LDAP signing and Kerberos hardening. Changes were tested in a laboratory, and each organization prepared its own rollback plan because local infrastructure determined the appropriate process.

Sources

← All Articles