A big challenge for many companies in their on-prem AD is that the UPN suffix doesn’t have a publicly routable domain name which is a requirement for e.g. O365, AAD and is preferred/recommended when using any cloud services. Continue reading
A good post about Kerberos Authentication problems with mixed 2003 and 2012R2 Domain Controllers – Ask DS Team
The Kerberos client depends on a “salt” from the KDC in order to create the AES keys on the client side. These AES keys are used to hash the password that the user enters on the client, and protect it in transit over the wire so that it can’t be intercepted and decrypted. The “salt” refers to information that is fed into the algorithm used to generate the keys, so that the KDC is able to verify the password hash and issue tickets to the user.
When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 DCs are present, there is a mismatch in the encryption types that are supported on the KDCs and used for salting. Windows Server 2003 DCs do not support AES and Windows Server 2012 R2 DCs don’t support DES for salting.
Have you ever had problems with account lockouts, changes occur on objects but you don’t know where it came from? There are good tools you could download and use for this kind of things but there is a built in tool that can help us immediately.
Repadmin is a tool for managing and troubleshooting replication between DC/DSAs. It’s built in in Windows server 2008 and later, it comes with 2003 Server if you promote it to a DC. You could also add it through RSAT.
If you open a command prompt and run repadmin /? It will present us a lot of options. In this case we are interested in the /showobjmeta option.
Showobjmeta: Displays the replication metadata for a specified object stored in Active Directory, such as attribute ID, version number, originating and local Update Sequence Number (USN), and originating server’s GUID and Date and Time stamp.
With this information we could track different type of changes in the domain by running:
repadmin /showobjmeta [DC Name] [distinguished Name] Continue reading
I read some news a while ago which inspired me to write this post.
It’s about a flaw in Kerberos and how Windows handles user account revocation. The flaw makes is possible for a user to have access to systems up to 10 hours after the account has been, disabled, deleted or locked out.
This is no direct news, and I believe that the 10 hours could be much greater if you look outside Kerberos and take the replication convergence in consideration.
When a user is deleted, disabled or locked out this has to be replicated to all replicas in the domain, meaning all the DCs needs to be updated with this information. Continue reading
A great 2 part blog series about Loopback processing of group policys.
For a quick summarize of a few recommendations that is no official best practices (but they maybe should be).
- Don’t use loopback 🙂
- Use a separate GPO for the loopback setting; ONLY include the loopback setting in this GPO, and do not include the user settings. Name it Loopback-Merge or Loopback-Replace depending on the mode.
- Avoid custom security filtering if you can help it.
- Don’t enable loopback in a GPO linked at the domain level!
- Always test in a representative environment prior to deploying loopback in production.
Even dough this is a year old post I wanted to help spread the word because there is still some crazy GPO configurations out there, and why not try to keep it simple 🙂
I was thinking of starting a new category in my blog called “You don’t need Domain Admin”.
I will use this to gather info about delegation from Active Directory out to the client in different cases and needs.
I personally think delegation of roles and responsibility is an important part of securing the infrastructure. If everybody had access to everything or has the ability to gain access to everything on himself, well then the security is gone.
I will start with something that I see almost everywhere and it can never be justified when you start talking about it. One of the first thing I look at when I’m in a new AD environment is the high-privileged group memberships. There is always so many users and service account members I always fall of the chair, and when I get up and ask about it I always get the same answers. Continue reading
A short notice about Administrator accounts privileges.
I guess you have noted that as an administrator (local or domain) you always has the possibility to take ownership of files, folders and objects in AD. Even if you don’t have any ACEs specified on that folder you always has the privilege to take ownership and change the ACLs.
Here’s the magic, the privilege. All users in a Windows network has the privilege to do something. E.g. logon to a computer, shut down a computer, change the system time. Privileges differ from access rights in two ways. Continue reading
First a tip for a great post about Aging and Scavenging of DNS records in Active Directory.
And second, I have heard about cases when server records hasn’t been updated for a while and gets cleaned up even dough they shouldn’t. Continue reading
One great thing with ADFS 3.0 is that it supports Group Managed Service Account (GMSA) which makes it easier and more secure to manage service accounts.
But when I installed a new ADFS Farm at a customer I ran in to some troubles. I have been able to reproduce it in one of my lab environments and wanted to share the story.
We had created a KDS Root key a couple of days before and gave it time to replicate. And then we installed the first ADFS server in the farm and all worked well using the GMSA account that was created during the setup.
But when we installed the next ADFS server we got some problems using the GMSA account, actually I got a couple of errors:
There were no SPNs set on the following service account ‘LABB\adfs$’. Specify the service account used to configure the other Federation Servers in the farm, or set host SPN for the farm on the service account.
The user name or password is incorrect
Unable to determine the Service SPN. There were no SPNs set on the following service account ‘LABB\adfs$’. Specify the service account used to configure the other Federation Servers in the farm, or set host SPN for the farm on the service account.
Unable to retrieve configuration from the primary server. The user name or password is incorrect Continue reading
Got some errors when I tried to run adprep /rodcprep stating that the adprep could not contact a replica for the NDNC DomainDNSZones and ForestDNSZones.
Adprep could not contact a replica for partition DC=DomainDnsZones,DC=corp,DC=secid,DC=se
Adprep failed the operation on partition DC=DomainDnsZones,DC=corp,DC=secid,DC=se Skipping to next partition.
Adprep failed the operation on partition DC=ForestDnsZones,DC=corp,DC=secid,DC=se Skipping to next partition.
Adprep completed with errors. Not all partitions are updated.
In my case it was because a Domain Controller recently had crashed and they were forced to do a metadata cleanup and seize the FSMO roles to a new DC. Continue reading