Description of problem:
Using the ldap attribute sudoHost, users always been refused to execute
a sudo command when the sudoHost is a IPV4 address or subnet.

Version-Release number of selected component (if applicable):
sssd 1.11.0
sudo 1.8.6p7
sssd-ldap 1.11.0
sssd-common 1.11.0

How reproducible:
Always (But only using NetworkManager service... When switching to "network" service,  this bug disappears ! )

Steps to Reproduce:
1. In OpenLdap, fill a user entry with a "sudoHost" attribute with a subnet: "192.168.101.0/24"
2. On a fresh Fedora 19 machine which is in the subnet "192.168.101.0/24", and which has NetworkManager service installed, the user tries to execute the command "sudo -l"
3. 

Actual results:
"User xxxx is not allowed to run sudo on machine"

Expected results:
The user is allowed to run sudo on the machine

Additional info:
This is an old anomaly we face for a long time.
After a little bit of debugging and digging in the code, it seems a filter on multicast address is wrong in
./src/providers/ldap/sdap_async_sudo_hostinfo.c:242:            if (IN_MULTICAST(ip4_addr->sin_addr.s_addr)) {
In fact, a conversion with "ntohl" is needed here:
./src/providers/ldap/sdap_async_sudo_hostinfo.c:242:            if (IN_MULTICAST(ntohl(ip4_addr->sin_addr.s_addr))) {

Without ntohl, the ipv4 addresses or subnets are seen has multicast and therefore are filtered... 

I see that a similar bug has been fixed in February for IPA:
https://bugzilla.redhat.com/show_bug.cgi?id=790105
https://fedorahosted.org/sssd/ticket/1804

It may also exist another similar bug in
./src/monitor/monitor_netlink.c:613:        return IN_MULTICAST(addr4->s_addr);

You cannot imagine how much i'm looking forward that this bug be corrected :-)