We are having a problem with our Windows 10 computers either not adding all of the Firewall rules from GPOs when the computer restarts or somewhere along the line.
We have multiple users that log onto the consoles (usually with a roaming profile) and a small percentage of them throw a firewall exception when trying to open necessary apps that should have been allowed through GPOs.
My questions are:
1.) Why is this happening?
2.) How to get information about the "USER" GUID that is returned from Get-NetFirewallRule?
Get-NetFirewallRule -Action Block
One partial result is:
TCP Query User{E2507D53-3CCE-4791-8BBF-9830003E90C5}
So how do i get information about this guid (E2507D53-3CCE-4791-8BBF-9830003E90C5)?
3.) Also, some of the computers that have this issue also block PSRemoting so I cannot fix this issue remotely, which is just as bad as the other issue!
Any ideas?
Thank you
PS: I have searched high and low for info about that GUID. It has become a personal goal to resolve the guid to an object name at this point.
So what is happening is when Windows prompts you for a application to create a firewall exception (even if you hit cancel), 2 rules are created by windows.
TCP Query User and UDP Query User
The rules are stored in the registry under the path HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
You might have this prompt with many applications. Which would mean the same name would be created over and over again. The GUID is just so that there is a unique name per application attempt.
Related
I want to be able to push a new group policy out with a powershell script (or scripts most likely) that will make all computers on our active domain update to the windows OS that we want. Currently there are hundreds of users and we don't have a way to update their computers other than doing it via remote desktop for each computer individually. But every computer has the .exe file required to update, just hasn't been run yet. Something like
wuauclt.exe /updatenow
I am also open to other suggestion on how to do this. I was thinking of sending all the users a batch file and having them run that and they could do it themselves. Any help would be appreciated and if this post wasn't specific enough I can answer questions or take it down. Thanks!
Never and I mean NEVER let user deploy updates on his/her computer themselves by clicking on some batch or exe file. Two reasons:
It will just not work and big part of machines will not be updated.
You are teaching users that they can run various and unknown batch files / powershell scripts / exe files, because it's safe.
Since you said "hundreds of users" I believe that you have some domain there.
What you might be looking for are the Group Policies (https://learn.microsoft.com/en-us/windows/deployment/update/waas-wufb-group-policy) or WSUS (https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wsus).
Today, I was able to create totally random and invalid SPN using the setspn command, but I dont understand why invalid SPNs are allowed. For example:
setspn -s RandomSvc/randomname.random.random valid_user was run successfully for valid_user in my domain (I substitute the actual user name here, but the user is a valid user in the domain).
Then if I do setspn -l valid_user, it will list this invalid entry.
I guess nobody can actually connect to this service since it does not exist. however, if I try to add a valid SPN, but typed it by mistake, I won't notice it until my application gives me an error. So why setspn does not do any validation (other than checking for duplicate with -s)?
The setspn command won't stop you from creating an invalid SPN, and for good reason, so there is no actual problem here believe it or not. Your definition of a valid SPN - that of a representation of an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, is not going to be enforced by setspn for reasons I am about to describe. According to a KDC, while an SPN represents an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, it doesn't actually have to be real at the time though. Here's why. Have you considered the case where perhaps the service, or even the machine it will be run on, will be installed later? The service and even the machine it is running on, and the DNS entry for said machine, doesn't have to be in place in the here and now when you create the SPN. Setspn.exe is simply a rudimentary tool which exists that allows you to create SPNs which will conform the RFCs for Kerberos. Its up to you to architect it right though, it's not going to hold anyone's hand in the process. I work for a large company and create SPNs all the time for services, and even for machines, which do not yet exist. That way the Developers or sys admins don't have to contact me to have an SPN created after the fact. They are following a project plan and savvy managers are going to have the SPN, DNS entires, IP addresses for machines, all planned out and created ahead of time before the OS admins get around to actually spinning up a live server for such use. So if setspn prevented people from creating an SPN for a service which is not yet up and running, there would be some very angry system admins out there. That is why it is allowed to create "invalid" SPNs, when you think it shouldn't. If you want something to do extra layers of validation not afforded by the generic setspn.exe, to catch mistakes before your application does, then you will have to create such a thing yourself. Ask yourself though, is this worth the time for something so specific? I mean, how often are you creating SPNs? This should all make sense to you now. I periodically run a setspn -X to catch duplicate sin my domain. I've never had the time, but I suppose I could also list out all the current SPNs in the domain and check if they are each currently valid, and take corrective action if they weren't. I'm sure there are probably more than a few which no longer are active. I don't consider it that big of a deal.
I am trying to create a powershell startup script for my domain controlled computers that will place the computer into the the specified OU. I would like for the variables to be taken on the local computer and then passed to the remote server. Once there I would like to execute the last two lines on the server.
The script below does work if it is ran on the server however as stated above I would like to be able to execute this from a client machine. How can I make this happen?
$computername = $env:ComputerName
$new_ou = "OU=TestOU,DC=Test,DC=Controller,DC=com"
Import-Module ActiveDirectory
Get-ADComputer $computername | Move-ADObject -TargetPath $new_ou
Note: Before anyone asks...my goal is to have the OU be determined by the client IP address. I understand that there are scripts that will do the discribed above but they run strictly on the server and query the DNS. I would rather have this run as a startup script on the local computer so I an better control which computers are being moved. At this point I am not interested in tackling this issue. Only the issue of how to execute the above lines on a local machine.
I assume you want to run the last 2 lines on the server because you expect that most of your domain computers won't have the RSAT tools or AD cmdlets installed.
The way to run it on a server is to have PowerShell Remoting enabled on the server and then use Invoke-Command.
That authentication is typically done with kerberos, though you could change the method, and you can supply credentials manually (though I doubt you want to be embedding credentials in the script).
You need to consider that the user making the AD changes needs permission to do so. Usually that's a domain admin, although permission could be delegated.
If you're running this as a startup script, it's running as SYSTEM. That account authenticates on the domain as the computer account (COMPUTERNAME$). This means that the computer account needs permission to move itself, which may mean it needs the ability to write objects into all possible OUs (I don't recall offhand which permissions are needed).
So you would either need to grant this ability to all computers (any computer in Domain Computers would have the ability to move any other computer to any OU), or somehow give each computer only the ability to move itself into the correct OU (which might still be too much in the way of permissions).
Another option is to make a customized session configuration on the server with a RunAs user. You could limit the users allowed to connect to the session (to Domain Computers), and limit the allowed commands so that the connecting computers can only run a limited set of functions/cmdlets. Even better, you can write your own function to do the change and only let them run that one. With the RunAs user being a privileged user in AD, the changes will work without the connecting user having the ability to make the changes directly, and without giving the connecting user the ability to use the privileged user or elevate their own permission. Remember that the connecting user in this case is the computer account.
This last method is, I think, the best/most secure way to do what you want, if you insist that it must be initiated from the client machine.
Reconsider doing this as a server-side process. Get-ADComputer can return an IPv4 address for the object, so you could use that instead of DNS. Centralizing it would make it easier to manage and troubleshoot the process.
I have a couple workstations that apparently has a GPO applied to them that implements some security measures. Unfortunately, it also appears that something has broke Powershell on them.
Whenever I attempt ANY cmdlet at all it hangs for a few minutes and finally gives a message "Provider Load Failure".
Does anyone know what may be causing this?
Create an organizational unit (OU) that doesn't have any GPOs applying to it. Move the computer into that OU, refresh Group Policy, reboot the computer, and see if it resolves. Assuming it does resolve the issue, slowly link the GPOs to the new OU, one by one, and see what breaks it.
There is a public queue named queue1 on machine A. I want to send messages to this queue from machine B. In order to achieve this, I wrote that c# code.
if (MessageQueue.Exists("machineA\queue1"))
{
label1.Text = "queue found";
}
else
{
label1.Text = "queue could not be found";
}
But Exists() method return false on machine B. The same code works well on machine C.
I found somethings related with msmq domain mode and workgroup mode. I think that msmq installed in workgoup mode on machine B.
How can I change this configuration from workgroup mode to domain mode?
HKEY_LOCAL_MACHINE\Software\Microsoft\MSMQ\Parameters\
Check the data for the REG_DWORD workgroup. Is it 1 or 0?
1 is workgroup mode.
0 is AD mode
Basically the difference between domain and work group mode is not defined by the value of the registry flag "workgroup" mentioned by #engin. This flag just reflects current operational mode but doesn't set it.
Whether you run in domain or workgroup mode is defined whether you installed MSMQ on domain controller or on a member server. Details about differences between these two modes can be found here: https://support.microsoft.com/en-us/kb/884974/
MSMQ 1.0 used to support domain mode only. Current MSMQ version is 5.0.
Next you may see quite interesting behavior when you installed MSMQ on your DC, your workgroup flag continuously reverts to 1 after each MSMQ service restart. This means that you have to grant Network Service account the Create MSMQ Configuration Objects permission to the computer object in Active Directory Domain Services before installing the Directory Services Integration feature on a computer that is a domain controller.
You may find details on how to do it here:
https://technet.microsoft.com/en-us/library/cc730960.aspx
MSMQ runs under the (less privileged) Network Service account instead of (all powerful) Local System account starting from version 4.0 (Vista/Server 2008)
So to answer #mkus question more directly to "set" domain mode you just install MSMQ on domain controller and make sure that proper permissions in place for Network Service account. Once this is done you well see it operating in domain mode with workgroup flag switched to 0 automatically to reflect this.
Also couple of links to clarify issues around MSMQ objects permissions and when/why you need to set them:
http://blogs.msdn.com/b/johnbreakwell/archive/2009/08/03/default-msmq-queue-permissions-have-changed-in-msmq-4-0.aspx. In short starting from MSMQ 4.0 Everyone and Anonymous Logon were removed from default MSMQ objects ACLs as precaution against DoS attacks (though there are exlusions to this change and Workgroup mode is one of those).
And as you may read in Technet article below you need to go a grant certain rigts to MSMQ objects either to Network Service OR to Computer accounts when installing the Routing Service feature on a Windows Server 2008 R2 (or later) computer that is not a domain controller OR when installing the Directory Service Integration feature of Message Queuing on a Windows Server 2008 R2 (or later) computer that is a domain controller. See details here:
https://technet.microsoft.com/en-us/library/cc749102(v=ws.10).aspx
Run Server Manager on the machine that is hosting the queue. Right-click on Features and click "add features"
Drill down under Message Queuing and under Message Queuing Services. You should see a checkbox for Directory Service Integration.
Check it and click install.
Usually you have to reboot the server for it to show the change.
I ran into some problems, no matter how much I installed or uninstalled MSMQ or restarted, I still wasn't able to use the queue. So I wanted to post some links here
http://support.microsoft.com/kb/935498
When it gets to a part about "To work around this problem, use the Active Directory Users and Computer Microsoft Management Console (MMC)...". Below is how you do that.
How to delete from active directory
http://technet.microsoft.com/en-us/library/cc773660(v=WS.10).aspx
"Delete stale computer objects" is the part you are interested in.
I also found this nice error in the event log "The Message Queuing service will not join the domain. An MSMQ Configuration (msmq) object exists in the new domain with an ID differing from the service ID. Please delete the MSMQ Configuration object in the new domain, restart the Message Queuing service, and log on again."- which helped to point out they way.
I have face this issue for windows server 2016, where even thought I was changing registry value to domain mode "0", it reverts to "1", after server restart.
To solve the issue on OS 2016, we need to uninstall below MSMQ feature as they are deprecated from OS 2016 onward.
Message Queuing Trigger
Multicasting support
Routing Service