Too bad I wasn't awake for the party, eh? I'll take a crack anyway.
I taught MCSE classes for several years, and Microsoft's recommendations were always fairly consistent between their various training materials.
Don't use a domain name you don't own for your Active Directory domain name (i.e. microsoft.com).
Don't use an FQDN for the domain that other DNS servers are already authoritative for (i.e. company.com)
Do use an FQDN for the domain that is globally unique (i.e. ad.company.com, corp.company.com).
I believe the ".local" TLD "recommendation" started about the time of Windows Small Business Server 2003. The ".local" TLD is not reserved by ICANN though it's doubtful, at this point, that it would ever be used "for real" on the Internet (the Zeroconf protocol has dependencies on the ".local" TLD, too, I believe).
I've been in too many environments where "company.com" got used for the AD Domain name, necessitating stupid ugly hacks involving manually copying DNS records from the Internet DNS servers into the DNS servers supporting AD. I've answered a boatload of questions on this site that came down to this poor domain name choice causing hacks to have to be implemented (having to run web servers to do redirects to the "real" "company.com" web site on every AD domain controller, etc).
I don't know why companies persist in doing the "company.com" naming scheme for AD domains. It only creates problems. There isn't any good argument why you should do it, and it "goes against" the basic tenet of DNS that only one set of DNS servers in the world should be authoritative for a given DNS domain name. (I often hear the "UPN suffix" argument. If you want users to have a UPN suffix of "@company.com", for example, you can do that w/o actually naming the domain "company.com". All your users can have "@whitehouse.gov" UPN suffixes if you want, regardles of the domain's name...)
I've always been partial to "ad.company.com", myself.
The "empty root" domain idea is purely a political construct. Originally (W2K timeframe) Microsoft touted "empty root" as a way to have isolation of security concerns between parts of an organization while still having a single AD infrastructure. Fortunately, they've let up on this attitude (though they haven't necessarily gone back and corrected all the documents that were erroneous) since it's been demonstrated that any member of "Domain Admins" in any domain of the AD forest can, fairly easily, make themselves into members of the "Enterprise Admins" group.
So, today "empty root" is only ever really used for political purposes. I would argue that there's no place for it at all because it adds needless complexity (never, ever have a multi-domain environmnet where a single domain environment will do) and offers no real advantages.
If you want security isolation between concerns in your organization you must use a multi-forest deployment (which is absolutely the least fun kind of environment and to be avoided at all costs).
when a client connect to a server, the client pickup a free tcp port it has between 1024 and 65535. On Linux/Unix, non root user can't pick up a port < 1024.
Then it connect to a well known port, like 80 for http...
The report claims that it can reach destination port if the source port is specific (22 and 25 in your sample), but it can't if it use a random port (between 1024 and 65535 for example). Client normally use random port and so your rule shouldn't take into account the source port number
So one of your rule is bad, because it allows flows if the source port is specific, whereas it should only filter on the destination port, which is the only static part between the two.
I guess you miss created one of your rule by inadvertly exchanging source and destination value
Best Answer
A Service Principal Name is a concept from
Kerberos
. It's an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs isservice class
/fqdn
@REALM
(e.g.IMAP/mail.example.com@EXAMPLE.COM
). There are also User Principal Names which identify users, in form ofuser
@REALM
(oruser1
/user2
@REALM
, which identifies a speaks-for relationship). Theservice class
can loosely be thought of as the protocol for the service. The list of service classes that are built-in to Windows are listed in this article from Microsoft.Every SPN must be registered in the
REALM
's Key Distribution Center (KDC) and issued a service key. Thesetspn.exe
utility which is available in\Support\Tools
folder on the Windows install media or as a Resource Kit download, manipulates assignments of SPNs to computer or other accounts in the AD.When a user accesses a service that uses Kerberos for authentication (a "Kerberized" service) they present an encrypted ticket obtained from KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted with the service key. By decrypting the ticket the service proves it possesses the key for the given SPN. Services running on Windows hosts use the key associated with AD computer account, but to be compliant with the Kerberos protocol SPNs must be added to the Active Directory for each kerberized service running on the host — except those built-in SPNs mentioned above. In the Active Directory the SPNs are stored in the
servicePrincipalName
attribute of the host's computer object.For more information, see: Microsoft TechNet article on SPN, Ken Hornstein's Kerberos FAQ