Александр

На JS: (язык тут не был указан)

const ip2int = (ip) => 
	ip.split('.')
	.map( (value, index) => Number(value) * 256 ** (3-index))
	.reduce( (sum,value) => sum + value, 0);
const range = (from, to) => ip2int(to) - ip2int(from);
console.log(range("192.168.1.0", "192.168.1.255"));
// 255 - т.е. броадкаст адрес он тоже считает

Суть - перевести ip в целые числа и вычесть их
Универсальный и простейший алгоритм перевода ip в число, например 5.24.0.0:
5 * (256^3) + 24 * (256^2) + 0 * 256 + 0 = 85458944

Обычно конфигурация компьютера имеет приоритет, но надо смотреть описание конкретной политики.

Этот параметр политики присутствует в папках «Конфигурация компьютера» и «Конфигурация пользователя». Если заданы оба параметра политики, параметр, заданный в папке «Конфигурация компьютера», имеет преимущество перед параметром в папке «Конфигурация пользователя».

Note: This setting appears in the Computer Configuration and User Configuration folders. If both settings are configured, the setting in Computer Configuration takes precedence over the setting in User Configuration.

Но в любом случае всё зависит от конечной программы, обрабатывающей политику.

Компрометация

Во-первых, сам подход - неверный!
Для команды - раздаются эл. ключи (или сертификаты).
Ключи передаются по иному каналу связи, нежели используемому для авторизации.
Ключи раздаются ролям проекта (dev1,dev2) или конкретно пользователям проекта.
Паролем можно (выборочно или принудительно) защитить авторизацию (при желании) самим владельцем ключа без участия центра сертификации (координатора проекта).
Пароли не знает тот, кто выдал доступ, т.к. доступ предоставлен ключам.
Доступы, обычно: REST API, SSH аккаунты или OAuth.