Greetings! Sam Salhi here from the Network Policy Server (NPS) team. One of NPS’s most powerful features is Pattern Matching. What makes it so powerful is the use of regular expressions when dealing with it.
Here’s a little example. Suppose that you want to proxy users from domain “foo.com” to a remote NPS server. You’re not interested in authenticating them locally. So what do you do?
You create a Connection Request Processing (CRP) Policy that will match, based on username and forward to the remote servers. How would that matching look like? Simple, a regular expression. So just enter: Foo.com.
But what about users that come in NT4 style domain names? You have two options. Either create a new policy or … Use the same policy matching field to enter the value now it will look like this
This all looks good. Since you’re only forwarding to a remote NPS, that will do some authentication as well. If there is no security associated with it. This would be fine. But what if security is an issue (as in, anyone from foo.com will be allowed access without authentication?)
In these cases, the rule must be tightened and made as strict as possible. So something like:
The stricter, the better. But remember you only need to do this when you’re allowing extra security. If you’re just using it to match while authentication/authorization will take care of security. Then you don’t need to make it too strict.
Remember that, “.” matches with anything. So 192.168.1.1 in regular expression world means *192?168?1?1* so something like: 192.168.121.221 would match it. If you want it to be strict, you must have the “.” Escaped and the beginning and end delimited. So ^192\.168\.1\.1$ this means that only 192.168.1.1 will match this policy.
Pattern matching is the core of the Attribute Manipulation features in NPS, but we’ll talk about these next time.
PS – More on Pattern matching Syntax with a quick refresher on Regular expressions here.