Tag Archives: SID

Converting Groups and Deleting Groups

In one of my previous blog posts I explained about the different security groups we can have in domain environment. Each and every group have the scope and type. But in some situations you may need to change these scope and type.

To change the type of the group (security or distribution) all you need to do is open the group and select the new type you need then click ok.

gchange

But if you need to change the scope, it will only allow you to do the possible convert only. The following table describes the possible changes.

 

To Domain Local

To Global

To Universal

From Domain Local

N/A

Prohibited

Permitted only if it doesn’t have other domain local nested groups

From Global

Prohibited

N/A

Permitted only if it’s not member of another group

From Universal

Permitted

Permitted only if it’s doesn’t have other universal groups as members

N/A

Deleting Groups

Each group in AD DS is assigned with unique SID (Security Identifier). This SID is used by AD to identify the permissions associated with the group.

When we delete a group from the AD DS it only removes the SID and the permissions associated with the group. It doesn’t remove any member object of the group. Also this SID will not be able to reuse. If you create a group with same name as you deleted it will get a new SID and you need to assign the permissions again as you do for new object.

If you have any question about the post feel free to contact me on rebeladm@live.com

Active Directory Domain Migration / Active Directory Forest Restructure

When plan for AD infrastructure design main concerns are to maintain the hierarchy and reduce the complexity. We can’t expect businesses to be same for years, as business grows we will also need to apply changes to the infrastructure design. For example company may move to a different business name, may be acquired by another company or else merge with another company. Any of the above situations may cause major AD infrastructure design change. This is where AD migration and Forest restructure techniques comes in handy.

There are mainly two types of AD migrations or restructure.

1)    InterForest – This is mainly happens when company involves with mergers, acquisitions which will need to integrate the resources between forests. When migrate between forest both target forest and source forest will exist. It make easier to roll back changes at any time.

2)    IntraForest – This is mainly apply when you try to reduce the complexity of the domain structure. So it will not involve with multiple forest. Source domain and target domain both will be under same forest. Unlike the interforest, if you need to roll back you need to go with reverse migration to get things back to previous state.

Let’s look in to the comparison between these two types against migration considerations.

Migration Considerations

InterForest

IntraForest

Object Preservation

Objects are cloned. Original objects will be remain in the source.

User and Group objects will be migrated and will not exist in source. Computer and Service accounts will remain enabled in source location.

Password Retention

Optional

Retained

Local Profile Migration

Tools like ADMT should use to migrate the local profiles

Will be migrated automatically

Accounts in Closed Set

Do not need to migrate

Must migrate

Security Identifier (SID) history

Optional

Required for the user, group and computer accounts. No need for managed service accounts.

Microsoft provides a great tool called Active Directory Migration Tool (ADMT) to help with the migration and domain restructure process. The latest tool can download using http://go.microsoft.com/fwlink/?LinkId=401534

ADMT

This tool simplifies the migration of AD objects as its automated most of the tasks. Using wizard with few clicks we can complete the process.

ADMT can run via GUI, command line or as a script. You can download complete guide for this tool from http://go.microsoft.com/fwlink/?LinkId=191734

If you have any question about post feel free to contact me on rebeladm@live.com

Configuring Trusts – Part 3

This is the part 3 of the series which explain about “Trusts” between infrastructures. If you not checked the other 2 parts yet you can find them in here.

Configuring Trusts – Part 1
Configuring Trusts – Part 2

In this article I will cover up the rest of the concepts, terms, involves with setting up a trust.

Security Identifier (SID) filtering

Microsoft Systems uses a structure known as SID to express its identities. Its act as a token. SID filtering is used to block users in trusted forest or domain being able to elevate their privileges in local forest or domain. This is important for external trusts as when you trusting you can control rights to provide credentials between domains.

By default windows 2012, windows 2012 R2 have SID filtering enabled. If you wish to disable this, you can do it using following commands. (https://technet.microsoft.com/en-us/library/cc794801(v=ws.10).aspx)

To disable SID filter quarantining for the trusting domain


Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>


To disable SID filter quarantining for the trusting forest


Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>


It is recommended to keep the default enabled state unless you have critical reason.

Name Suffix Routing

In an organization it may have different UPN (User Principle Name) suffixes used with in its forest. For example Contoso LTD. May use contoso.com, mycontoso.net, companyA.org as name suffixes. But when you creating a trust you may not need to allow users from all these suffixes. With Name suffix routing we can enable or disable the UPN suffixes which will involve with the trust operations.

I will demonstrate how we can do this in next post which will go more in to real world configurations.

Trust Authentications

Trusts can use 2 authentication protocols. By default it uses Kerberos Version 5. If it’s not supporting it use NTLM Authentication.  In order to initiate a trust, the administrator need to be a member of domain admin group or enterprise admin user group. Trust needs to initiate in both sides.

Trust Components (https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx)

IC195612

Before initiate trusts it is important to make sure following ports are open in both sides.

UDP Port 88 – Kerberos Protocol
TCP and UDP Port 387 – LDAP
TCP Port 445 – Microsoft SMB
TCP Port 135 – Trust endpoint resolution

This is the end of a part 3 of the configuring trust series and in next article let’s look in to real world setups. If you have any questions regarding the post feel free to contact me on rebeladm@live.com