An Active Directory is a database that holds information about the security of an organization. It stores user accounts, and security settings to help organise all the information. Active Directory also stores a list of security groups that are created by the organisation to hold different levels or types of access permissions.

Active Directory is a way that you can show people your home. If you are not careful and give too much permission to people, then it can be easy for others to do bad things. Within Active Directory, there are numerous ways to configure what users and groups have administrative access.

In this blog, we will go straight to the point by going through exactly what security groups in Active Directory are and how they differ from distribution groups. In addition, we have provided the most important bits of knowledge about them such as which can be used for, the scope of their powers and much more.

What are Active Directory groups?

Active Directory groups are an abstraction, or a way of grouping like-minded and similarly permissions assigned security principals. These are typically people that need to be granted the same access privileges in order for work to get done. Active Directory groups can also include computers as these have permission too (just not as much).

The two types of Active Directory Groups are Security and Distribution Lists.

Security Group: A security group is made up of members who work together to achieve the same goal or purpose within an organization such as the IT department or marketing team. They can be created for general purposes like managing access permissions for all users on public folders \marketingprivate_folders so that only approved accounts have permission to read from it while others will not be able to do so without being granted explicit permission, with one click. Another example would be creating a security group called “Windows Administrators” which you can then assign administrative privileges on Windows servers by adding them at MI Control.

Distribution Group: Distribution groups are created for the purpose of sending e-mail messages to a group of recipients, typically in response to an event or other specific request. You can create distribution lists by adding one person at a time but you save much more time when creating them this way if there are many people that need to be added simultaneously.

Active directory security groups vs distribution groups

Security groups are security boundaries, not distribution boundary. A distribution group is a logical grouping of recipients for the purposes of sending email messages to them at one time or another. Security groups enable you to assign permissions and privileges to those members while distribution lists help with mailing list management by auto-adding people to the “To” field when it’s created in Outlook or Outlook Web Access.

Distribution Lists instead function like mailing lists that will send out emails with messages and updates whereas Security Groups more often control who has access to certain files or systems within your business environment.

What are Active Directory security groups?

An Active Directory security group is used when the primary concern is managing risk-limiting access from unauthorised intrusion or cyber-attacks while maintaining productivity and efficiency.

Security groups are a way to control access to resources in your organisation. Members of security groups are authorised to access the resources for which the group has been granted permission.

Functions of Active Directory Security Groups

Within an Active Directory environment, security groups can provide a way for organisation administrators and system owners to control who in your business is able to do certain things with data or files on specific computers or systems. The ability to set permissions at this level ensures that no one person can take ownership over everything in their area. In addition, it allows people within your organisation different levels of access based on what they need rather than having everyone be admins, users etcetera. This also helps prevent accidental damage from occurring if someone doesn’t know what they’re doing when browsing through shares on remote systems where permissions aren’t as strict.

Active Directory security groups are typically used in an Active Directory environment to provide a way for organisational administrators and system owners to control who can do certain things with data or files on specific computers or systems. The ability to set permissions at this level ensures that no one person can take ownership over everything in their area. In addition, it allows people within your organization different levels of access based on what they need rather than having everyone be admins, users etcetera. This also helps prevent accidental damage from occurring if someone doesn’t know what they’re doing when browsing through shares on remote systems where permissions aren’t as strict.

Scope of Active Directory security groups

The scope of security groups is determined by the type you are creating and who has permissions to view or edit the group. Domain Local Security Groups, for example, can only be viewed within a domain whereas Global Security Groups can be accessed from any domain in your AD environment.

Local groups are the most basic scope. They’re called Local because they are defined and available to the local/specific system.

A Domain local security group (DL SG) is a security group that exists on an individual computer or server’s Active Directory and cannot span domains as it does not have universal privileges as global groups do.

The DL SGs protection level at this time prevents other administrators outside of their respective domain from viewing them unless they’re granted access through delegation with administrative rights over the system where these LDGs exist. This makes them ideal for when you need to restrict access to a security group.

Universal groups in Active Directory are groups that are available to all domains of an organisation, and can contain users from any domain.

Global security groups in Active Directory have a universal scope which makes them ideal for when you need to grant access rights or delegate permissions quickly across many systems and/or multiple domains.

Why Should You Use Active Directory Security Groups?

Active Directory security groups allow you to set permissions on the computer. This means that if an account is a member of a security group, it will have certain privileges and restrictions automatically applied based on what has been configured in Active Directory for that particular security group. You’re able to see which accounts are members by using Windows PowerShell commands or cmdlets.

This is a pretty simple concept, but it’s important to understand because security groups are used for so many different things. There are two types of security groups: Local and Global. Each one fulfils specific needs in Active Directory administration or access control configurations.

Active Directory Security Groups have two types- Global and Domain Local security groups. Domain local security groups are only applicable on the domain it was created, global security groups are not.

Active Directory Security Groups function at a specific scope- either ‘Domain Local’ or Global’. The Domain Locals have their own group policies unique to that domain and what is applied to them is restricted by permissions of who can manage this object; while the Global security groups are applied to all domains and have the ability to be managed by an administrator.

Domain Local security groups can only contain objects from that domain while Global Security Groups can include any object in Active Directory irrespective of its location or Domain origin. Active Directory Security Groups provide permissions at different levels- ‘read’, ‘write’ and ‘full control’.

The scope of a security group can be limited to the domain it is in or expanded across domains, forests, etc., depending on its type and how it was created/added to Active Directory (domain local security groups are automatically global).

How To Create A Security Group In Active Directory?

1. Log into your active directory server.
2. Navigate to the “Administrative Tools” folder in Windows (or open up a command prompt and type ‘dsacls’).
3. Click on the right arrow next to an existing security group’s name, or click “+ New”. This will open a dialog box showing you various options for what type of security groups you would like to create. You can choose from three types of security groups- global, universal/domain local, and domain local. The first two are appropriate if you want all users within that organizational unit to share permissions with these new groups; while domain local is appropriate if only those within one department should have access. If this doesn’t ‘t sound like what you’re looking for, simply choose the “All” option.
4. After selecting your security group type in the previous step, click on the radio button next to ‘everyone’ or select who has access within that department from the list below- these are users and groups labelled as a security principal with an SID (Security IDentifier).
5. Click OK. If this is a domain local security group, it will be automatically added to any global security groups managed by that organizational unit; if not selected before clicking OK.

And there’s more about how Active Directory Security Groups work!

Active Directory Security Groups help protect data from unauthorised use at different levels of privilege across multiple systems/users networks.

Active Directory Security Groups Best Practices

• Control who has access to specific directories using permissions granted via ACLs (Access Controls List ss Control Lists).

• Ensure that the people who have administrative rights to your domain controller are trusted professionals using security groups.

• Use Active Directory Security Groups for more efficient administration and management of security permissions on a per-user or per-group basis.

• Create new AD DS objects in batches as opposed to individually, which can save time when you need to create many at once. a large number of objects.

• Reduce the risks associated with security breaches by limiting access to only necessary AD DS objects and data, such as specifically assigning permissions on a per-object or per-group basis via security groups.

• Determine what type of group security you want to use: Domain Local Security Groups vs Global Security Groups.

Conclusion

It’s important to keep your Active Directory security groups as secure as possible. Since the risk of a hack is higher than ever before, it pays off to be vigilant in this regard. You can do so by following these tips:

Active directory security groups are a type of container object within Windows Server AD DS (Active Directory Domain Services) which can be used by administrators who are responsible for managing permissions across the network.

Conclusion paragraph: As you can see, there are many active directory security groups that a company would find useful to create and maintain. It’s important for your organization to know how these work so they may be able to secure their AD with the best practices in place. If this sounds like something you could use help with, our team of Cyphere security experts is ready and waiting to take on any challenge that comes your way! What other questions do you have about Active Directory Security Groups?

What are the benefits of Azure Active Directory (Azure AD) over an On-Premises Active Directory (AD)?

Reducing Administrative Overhead: The first and foremost benefit of using Azure AD over an on-premises AD is that it reduces administrative overhead to some extent as organisations adopt cloud applications like Office365. 

Security: Azure Active Directory provides an insight to admins for unauthorised access and account hijacking by working with an Identity Protection tool. An on-premises AD DS would require a third-party tool for this.

Seamless Single Sign-On: Azure AD offers Seamless Sign-On functionality to access a large number of SaaS applications, and Azure AD joined devices performing user authentication with OpenID connect/OAuth protocols.

Enhanced Self-Service for Group Memberships: Azure AD provides enhanced self-service for group memberships, meaning that business users don’t have to rely on IT support to update Active Directory; a change is made in the group memberships. Everything in Azure AD can be done through the Azure AD admin portal.

Easy License Management: Azure AD provides easy license management for several Microsoft services through the Azure AD admin portal.

Guest Collaboration: Azure AD allows you to invite guest users into your directory to assign access while their organisation manages their credentials.

Other Features: Additional features in Azure AD, like Privileged Identity Management, Tenant Restriction Capability, Identity Secure Scores based on Microsoft’s security recommendations and best practices, make it an important tool to use alongside an on-prem AD.

Limitations of Azure AD: When compared to an on-premises Active Directory, Azure Active Directory has the following limitations:

Security: To ensure secure access to services, a Security Mobility and Security E3 is required as a minimum licensing purchase, as you cannot put a firewall around web applications. 

No Support for Integrated Windows Authentication Protocols: Azure AD DS does not support Kerberos/NTLM authentication, so any native/local applications or services using these as their authentication mechanisms will cease to function.

LoB Applications as a SaaS Model: An organisation’s Line Of Business applications will have to be delivered as a SaaS model.

No Support for Active Directory Certificate Services: Azure AD does not support AD Certificate Services like the on-prem AD. If the organisation uses client-authentication certificates to access an organisational wireless network, it will consider other authentication options.

Flat Structure: Azure Active Directory Domain Services (Azure AD DS) has a flat structure, no Organisational Units or Forests.

Integrating Azure Active Directory with on On-Premises Active Directory

There are three ways of integrating an On-Prem AD with an Azure AD:

1. Password Hash Synchronization (PHS): This is conceptually similar to AD Replication, as the passwords are sent to the cloud from the on-premises AD DS. This is made possible via a service account created through the installation of AD Connect.
2. Pass-Through Authentication (PTA): PTA keeps the credentials on-premises but allows users to have the same password for Azure AD and on-premises AD. For example, when a user authenticates into the OWA, they enter their credentials into the web portal of Azure AD; Azure then encrypts this set of credentials using the PKI and sends it to the on-premise domain controller, which verifies these credentials and sends an all-good status back to Azure AD.
3. Active Directory Federated Services (AD FS): Azure AD can connect back to the local, on-premise AD DS via the AD FS. With AD FS, Azure AD is set as a trusted agent for federation and allows for authentication with on-premises credentials. Although Microsoft released an update to Azure AD Connect back in 2017 called the Seamless Single Sign-On that offers a simpler solution to Single Sign-On than AD FS.

What is ADFS in Azure AD?

ADFS in Azure AD provides simplified, secure identity federation and Web Single Sign-On capabilities, providing users to authenticate using on-premises AD DS credentials and access all the resources in the cloud.

Is Azure AD the same as AD FS?

Azure Active Directory uses Active Directory Federation Services (AD FS) to integrate the cloud-based domain services (Azure AD) with the on-premises Active Directory Domain Services (on-premises AD DS).

Does Azure AD use ADFS?

Azure AD Domain Services may use Active Directory Federation Services (AD FS) if the organisation requires the cloud-based identity management services (Azure AD DS) to be integrated with the local, on-premises Domain Services (AD DS), enabling the users to use web-based and cloud-based resources, like Office365 and Outlook for Web.

Migration from an On-Premises Active Directory to Azure Active Directory

When a project involves migrating an on-prem AD to the Azure active directory domain, special considerations should be given to the authentication mechanisms being used in the local AD, as discussed above, which has no support for Integrated Windows Authentication protocols.

Another point that needs attention while migrating to Azure AD is handling the LoB applications. There is also a question on how to handle the business applications. Many legacy business applications and infrastructure replace and file archives to Azure Files and move active files to Microsoft Teams and SharePoint servers.

If you can’t get all your applications as SaaS apps and resources and have some that still need to run on your own servers, then you can migrate these to VMs (virtual machines) in Azure. If those VMs need to be domain joined, you can either deploy a Domain Controller on another VM in Azure or use Azure AD Domain Services, a PaaS service (you don’t have to manage it) for domain joining Azure VMs. Azure AD DS automatically synchronises with Azure AD, so all your users get the application access you want.

While a Lift and Shift is also possible for applications, the local on-prem AD must still be dealt with.

Does Azure AD replace Active Directory?

You can not replace an on-premises Active Directory installation with Azure AD. Azure AD is not an actual replacement of AD DS. According to a Microsoft’s representative:

“Azure Active Directory is not designed to be the cloud version of Active Directory. It is not a domain controller or a directory in the cloud that will provide the same AD capabilities. It actually provides many more capabilities differently.

That’s why there is no actual “migration” path from Active Directory to Azure Active Directory. You can synchronize your on-premises directories (Active Directory or other) to Azure Active Directory but not migrate your computer accounts, group policies, OU etc.

Azure Active Directory is an identity and access management solution for hybrid or cloud-only implementations. It can extend the reach of your on-premises identities to any SaaS application hosted in any cloud. It can provide secure remote access to on-premises applications that you want to publish to external users. It can be the center of your cross-organization collaboration by providing access for your partners to your resources. It provides identity management to your consumer-facing application by using social identity providers. Cloud app discovery, Multi-Factor Authentication, protection of your identities in the cloud, reporting of Sign-ins from possibly infected devices such as Windows 10, leaked credentials report, user behavioural analysis are a few additional things that we couldn’t even imagine with the traditional Active Directory on-premises.

Even the recently announced Azure Active Directory Domain Services are not a usual DC service that you could use to replicate your existing Active Directory implementation to the cloud. It is a stand-alone service that can offer domain services to your Azure VMs and your directory-aware applications if you decide to move them to Azure infrastructure services. But with no replication to any other on-premises or cloud (in a Virtual Machine) domain controller.

If you want to migrate your domain controllers in the cloud to use them for traditional tasks, you could deploy domain controllers in Azure VMs (virtual machines) and replicate via VPN.

So to conclude, if you would like to extend the reach of your identities to the cloud, you can start by synchronizing your Active Directory to Azure AD.”

Common Attacks against Azure AD

1. Password attacks (Credential stuffing and brute-forcing): Attackers love to collect many usernames and passwords from data dumps as a result of breaches and then try to brute-force their way into Azure AD Accounts. Good and complex password policies coupled with multi-factor authentication are good mitigation against Azure AD or AD attacks.
2. Phishing Attacks: Phishing is the most common attack in the corporate world, which may lead to credential theft or malware infection, allowing an attacker to gain an initial foothold in the corporate environment and then compromise the entire infrastructure or exfiltrate data out of the organisation. Azure AD gives you a warning when an email is received from someone outside the organisation.
3. Azure AD Skeleton Key Attack: This attack is possible with Azure AD Connect when integrating Azure AD with the on-prem AD using the Pass-Through Authentication (PTA) method. With this method, a server called the “Azure Agent” is deployed in the on-premise AD, which, if compromised, can create a backdoored access as any synchronized user.

Conclusion

AD DS is essentially LDAP that provides identity and authentication, group policy, trusts and security settings with on-premises IT environments. Azure AD is cloud-based identity and mobile device management providing authentication and authorisation services for multiple resources such as Office 365, Azure portal, or any SaaS applications. This is all under cloud Azure AD.

Azure AD DS provide managed domain services with traditional AD DS features. This allows domain join, group policy, LDAP and Kerberos and NTLM authentication and makes it easier for businesses to utilise the traditional web applications without additional requirements (as part of lift and shift strategy).

Get in touch to discuss your Microsoft Active Directory security concerns.