Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 760
  • Last Modified:

Is it possible to create an exception for an IP-adress, or a server, in Group Policy NTLM security settings?

If possible, we need to make an exception for a specific server, from the Group Policy, NTLM security settings. The Group Policy is configured as follows:

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients > Enabled
Require NTLMv2 session security > Enabled
Require 128-bit encryption > Enabled

------------

Network security: Minimum session security for NTLM SSP based (including secure RPC) servers > Enabled
Require NTLMv2 session security > Enabled
Require 128-bit encryption > Enabled

From what I could see, there isn´t any option of making such an exception from the Group Policy editor GUI. But perhaps I am missing something, or there might be a way of doing this with some kind of a script...?
0
andre_st
Asked:
andre_st
1 Solution
 
NotVeryFatCommented:
You could try creating a WMI filter, adding the following line, and then applying to the appropriate Group Policy:

SELECT * FROM Win32_ComputerSystem WHERE Name <> 'ServerName'

This should mean that the Group Policy would apply to all except this server.
0
 
Krzysztof PytkoSenior Active Directory EngineerCommented:
Try with Group Policy Security Filtering and add there that server account and set up deny read/apply this policy. Instead of adding single server to that GPO security filtering, you can create special group add it there and place this server into this group.

More about GPO Security Filtering at this article
http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Security-Filtering.html

Regards,
Krzysztof
0
 
andre_stAuthor Commented:
I see now that I was a bit unprecise in my question...sorry about that.

The problem is that I want a DC server, to make an exception in its loaded Group Policy settings - so that it wont require 128 bit encrypted communication from a specifc server in the network.

If I use security or WMI-filter to target the DC-server, that would just mean that it wont require 128 bit encryption, regardless of which computer client it is communicating with. And that is not the intention. I just need the DC to make an explicit exception when it comes to a specific server, and still maintain the security settings when it comes to all other servers/clients.
0
Managing Security Policy in a Changing Environment

The enterprise network environment is evolving rapidly as companies extend their physical data centers to embrace cloud computing and software-defined networking. This new reality means that the challenge of managing the security policy is much more dynamic and complex.

 
Netman66Commented:
Hello again!

I understand exactly what you're asking.

There isn't a method (currently) to allow you to do this.  As has been stated already, you can prevent this policy from applying to this server, however it does exactly what you already know - turns off the 128-bit requirement altogether.

You pose an interesting question, and one I am going to bring up at the Microsoft MVP Summit in two weeks.

I suspect their response to be more of a question of whether adding a "middleman" or server in the middle would be viable.  There are other scenarios where two servers cannot communicate directly but can be configured to communicate through a third server and I'm wondering if we could somehow make this work for you too.

Exactly what type of traffic is being prevented by this 128 bit requirement?  If you know the protocol and ports, that may be of value when trying to provide you with a workaround.

Let us know.
0
 
andre_stAuthor Commented:
Thanks for your reply.

Regarding:

"There are other scenarios where two servers cannot communicate directly but can be configured to communicate through a third server and I'm wondering if we could somehow make this work for you too."

I´m afraid this option will not be acceptable from our clients point of view.

We have developed an application that works as an central application server software (contains user database, and other specific user data) - that works in conjunction with some of our other client software. To make it easier for the users to log in to these client application, we have implimented a "Single Sign On"-function that lets the application server authenticate the user from the AD Domain Controller. So from the users perspective, they never need to log in to these programs, as it is enough to have been authenticated during the windows domain login.

During the authentication, the application server communicates with the computer client and the AD Domain Controller with the https/ssl-protocol. So even if the application server software in it self is a "middle man", it should be quite safe. But this application does not support 128bit encryption, and there lies the current problem...

Those customers that have theire NTLM-Group Policy set to 128bit encryption, cant get the Single Sign On function to work.

As the Application Server uses https/ssl, I would regard it as rather safe if one could configure the Group Policy to make explicit exception for a specific IP-adress, or a server.
0
 
Netman66Commented:
Since your app is taking Windows Integrated Authentication, the OS is doing the hard part in securing the comms between AD and itself, so it should only be a matter of leveraging the OS calls using a shim or making the determination based on the local access token presented by the client.  Since the client is already authenticated to that application server (if it uses a share) then the only processing it needs can be localized and not have to go to the DC - basically circumventing the need for a 128-bit call.

Just thinking out loud.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now