Domain users can’t login, if comodo firewall is ON.
When comodo firewall is OFF, domain users can login and work.
If comodo firewall turn ON during users can work, all working OK, but if I obtain IP address
at workstation, workstation can’t recive new IP.
What can I do?
What shows up in the logs (in CFP 2.4, click Activity → Logs)? And what do your Network Monitor rules look like?
What shows up in the logs (in CFP 2.4, click Activity → Logs)?
Good, no any records about bocking local packets 
And what do your Network Monitor rules look like?
Default settings and I added trusted zone (my local zone).
1.CFP2.4. is ALLOW ALL
2.users login
3.login ok
4.all working ok
5.refrehs IP at workstations
6.OK!
7.CFP2.4. is CUSTOM
8.refrehs IP at workstations
9.can’t obtain new IP.
The classic DHCP question, of how to get a dynamically assigned address.
You’ll need to add this rule, fairly early in your Network Monitor ruleset.
Allow Protocol UDP In&Out from any to host 255.255.255.255 where source port is any and destination port is 67 or 68
The host address of 255.255.255.255 is a special address used by DHCP as a LAN-local broadcast address. The client trying to boot will ask for any listening server, and the server will answer as a broadcast, as the client doesn’t have a real IP address yet (it’s still trying to get an address). Port 67 is used by the server, and port 68 by the client.
Be aware that CFP 2.4 does have some issues with DHCP, so this rule may not be sufficient. You’ll have to try it to find out.
No, not work.
Let’s try a more drastic rule to see if this opens up the DHCP exchange:
allow Protocol UDP In&Out from any to any for any source port to destination port 67 or 68
If that doesn’t work, then you’re likely encountering a known problem with CFP stateful packet inspection. The DHCP handshake sends two back-to-back packets that differ by only a few bits. The CFP packet inspection doesn’t see the packets as being different, and so blocks the second packet, which is the handshake acknowledge that completes the IP address assignment. The result is that the client just hangs until it reaches a timeout condition, and then self-assigns an IP address in the 169.254.x.x address range. To my knowledge, there is no workaround in CFP 2.4.
Thanks. I will try. now.