Static IP Issue with Windows Server 2022
Hi Community, I installed my first Windows server to learn about the server and Active Directory. I installed Windows Server 2022. I configured a static IP and disabled IPv6. Then I installed Active Directory/DNS. After the reboot, the system is up, and I can access the internet and ping hosts. However, there is a world icon (No internet access) instead of a computer icon (internet access). In the static IP config, it replaced the DNS with 127.0.0.1, I know it'll use the local host as DNS. When I click on Network & Internet settings and Troubleshoot, I see an error 'DHCP is not enabled for "Ethernet"'. The only way it goes away is if I change the static to automatic. How can I fix this issue? Thanks, Also, I added forwarders such as 1.1.1.3 and 1.1.1.2 to DNS.
Protect Tier 1. Sleep well at Night.
In case you have not yet protected Tier 0, consider reviewing our article about protecting Tier 0 the modern way. Tier 1 is more difficult to outline as there are typically different security levels, from highly critical (e.g. personal data or business secrets) to informative, or even public information. What remains the same is the “assume breach” approach: no matter which (Tier 1) system gets compromised, the infection must not spread. What causes us a lot of headaches is something we call “Permanently privileged Tier 1 accounts”: accounts which are members of the Local Administrators group on most (or even all) Tier 1 servers and left there indefinitely. This type of accounts draws attackers like moths to the flame, because by compromising a single account, attackers can gain full control of Tier 1. Optional Refresher: Lateral Movement (in Tier 1) In general, the term “lateral movement” refers to a group of techniques cyber criminals use to explore an infected network to find vulnerabilities, escalate and cement access privileges, and finally reach their ultimate target. It is called “lateral movement” because of the way the attackers move sideways from their initial point of entry to device, to application and so forth. The illustration below depicts how attackers move laterally across Tier 1: Attackers compromised T1-Server-01. Thanks to LAPS, lateral movement to other Tier 1 servers using the (local) Administrator account and password is unsuccessful. T1-Admin-01 logs on to T1-Server-01 to perform some administrative tasks, thereby exposing reusable credentials to the attackers waiting for their chance. Attackers steal reusable credentials from the server’s memory. Attackers move laterally to all T1-Servers accessible with the credentials stolen in step (3). Tackling the Security Challenge of standing Privileges Just-in-time (JIT) administration in Active Directory is a security practice that temporarily elevates user privileges only when needed, which massively reduces the risk of misuse. It works by granting privileged access for a limited time, ensuring that users can elevate only on a limited number of devices at the same time and are automatically removed from privileged groups after a defined period. By introducing JiT, we can get rid of identities which hold permanently privileged access to many systems at the same time. Let’s be very clear on this: JiT will not prevent a single server or account from being compromised, but it can prevent the attack from spreading by minimizing the window of opportunity for attackers to exploit elevated privileges. By limiting the duration and scope of privileged access, JIT administration reduces the chances of attackers moving laterally across the network and gaining control over critical systems. Due to complexity, pricing, and environmental overhead of many commercial JiT solutions, we were looking for an easier way to achieve secure JiT on a budget. The solution developed by Andreas Lucas and Andreas Luy is based on a PowerShell scripts, comes with a graphical user interface and is published on Github. So, what is still holding you back from protecting Tier 1? JiT on a Budget Please note: This is not an "official" Microsoft solution, but a project created and developed by people working in Microsoft Security Enterprise Services (which used to be known as Microsoft Consulting Services some time ago). The tool is written in PowerShell. Please review carefully before introducing in your environment. When doing that you will find some not yet documented features. We are working on improving the documentation. We also want to emphasize that implementing this tool is only one part of the journey to protect Tier 1 against today's attacks. JiT Configuration The configuration for the JiT solution will be stored in Active Directory. To make this possible an Active Directory Schema extension must be implemented. Even though most AD admins do not enjoy schema updates, AD turned out to be the perfect location for storing the JiT configuration: it is highly available by default, is less likely to be messed up (or even deleted) than config files. The solution uses an Active Directory object to save the general JiT configuration (like OU locations for T1-Servers or maximum allowed elevation time). In addition to that, an individual object is created for each T1-Server and a Container is used to hold individual objects for allowed delegations (in other words: which user is allowed to request elevation on which server/OU). JiT Automation After the JiT solution has been installed and configured, a Scheduled Task will be running on the JiT Management Server every few minutes (step 1 in the illustration below). This task runs in the security context of a gMSA (group Managed Service Account) and monitors Active Directory for newly added Tier 1 servers (step 2). In case a new T1 server is found, the Scheduled Task creates an individual AD group for each new Tier 1 server (step 3, e.g. T1-Admin#Server-01). The group is automatically added to the according Tier 1 server’s (local) Administrators group through Group Policy (step 4). All these “Jit administrative groups” created are Tier 0 groups and cannot be modified by Tier 1 assets. At this point no T1-Admin is yet a local Administrator on any Tier 1 server. T1-Admins who want to self-elevate to local Administrator on a Tier 1 Server, must log on to the JiT Management Server (step 1 in the illustration below). Please note that the JiT Management Server is classified as a Tier 0 system. There they start a PowerShell-based elevation UI Tool and select the Tier 1 Server they want to request elevation for (step 2). A Scheduled Task running in the security context of a gMSA then adds their T1-Admin account to the T1 Server’s specific domain group (e.g. T1-Admin#Server-02) together with the requested time-to-live (TTL) (step 3). Now the T1-Admin-01 is an indirect member of the (local) Administrator’s group on the T1-Server-02 and can log on to this server to fulfill his admin tasks (step 4 in the illustration above). After a defined time span (TTL), the Privileged Access Management (PAM) optional feature ensures that the T1-JiT-Admin’s account is removed from the T1-Admins#T1-Server-02 group. In addition, the gMSA-based task ensures that the Jit-Administrator Groups will not contain ANY permanent membership in the (local) Administrators groups. The PAM optional feature essentially unlocks two new capabilities in the AD Forest: Temporary time-based group memberships, and shadow principals. Both were introduced to allow the implementation of a Red (or bastion) Active Directory Forest, using a MIM (Microsoft Identity Manager) for requesting temporary privileged access. However, our JiT solution only leverages the former to ensure that after the specified time has elapsed, the user will be automatically removed from the security group (without administrator intervention). Find more information about possible drawbacks when enabling the PAM option feature, check out our colleague's blog: https://ryanries.github.io/?title=possible_performance_pitfall_privileged_access_management.html Let’s get started Now is the time to protect Tier 1. For too long, this critical layer has remained vulnerable—not because it’s unimportant, but because safeguarding it seemed too complex or resource-intensive. That’s no longer the case. With a simple and effective solution now available, there are no more excuses. Protecting Tier 1 is not just a technical necessity—it’s a strategic imperative. Let’s take this opportunity to secure what matters most, before it’s too late. The code and detailed documentation are provided at https://github.com/Kili69/Just-in-time.
Entra Connect - Access to onsite Server Shares
Will setting up Entra Connect and syncing AD IDs with Entra IDs provide access to on Prem Windows server shares? We are planning for our migration to the cloud and have a bunch of Windows server shares that users currently access with their Active Directory accounts. Setting up Entra Connect and syncing the AD accounts to Entra ID Accounts provide the same access to these shares? Migrating the file shares to Entra ID is a bigger migration project probably further down the road. I found this article but it's the other way around, Hybrid identities accessing Azure shares: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune
Adding Distributed COM Users group in the built-in groups for AD
I came across this question from one of my connections in my network. "A user was added to the Distributed COM Users group in the https://bit.ly/2U7Zarc however it seems to be doing nothing for allowing that user to access dcom on the servers. Isn't the point of the built-in groups is that they are already defaulted to the correct permissions and setup on object in the AD structure? Is there a way to test? An effective access on an OU with that group was done and it was all denied. Is this the right way to test those particular permissions" I suggested the following: As the added users are not able to access the dcom server. In that case it is good to check the dcom remote access permissions in the component services. Remote access and local access should be enabled. If it is not then any user part of distributed com users group will not be able to access the dcom servers. Let me what are your thoughts on this. Thanks.
How Do I - Run a PS Script automatically when Insert USB drive to verify credentials, start program?
I want to have a PowerShell script that runs automatically when I insert a USB drive. Here's exactly what I want to see happen: Step 1. -- Insert USB Step 2. -- A script runs automatically that pops up a window requesting I enter my credentials Step 3. -- Those credentials are verified against Active Directory Step 4. -- If the credentials are good, then a program is executed (let's say outlook.exe) Step 5. -- If the credentials are bad, it prompts me a maximum of 3 times before NOT running the program and displaying a bad credentials message or something to that effect. Info: The program (outlook or anything), PowerShell, and the script will all be on the USB drive. Please forgive me if something like this is already posted but I did a search and couldn't find exactly what I was looking for. Any help would be greatly appreciated and I promise to contribute when I become good at this. Thanks.
