LDAP setup questions. TAC has us more confused than we need to be.

[Dustin Anderson]

OK, se we want to move out company from using  the RAT table to querying and LDAP directory. 

Right now, my co-worker's email is in this AD dir and mine is not. I made a test policy that any email from my gmail to anyone in the LDAP group would hit this policy. We do not have anything set on the listener.

Now, if I email from my gmail to alex@myco.com it hits the rule as expected, but if I email from my gmail to dustin@myco.com it hits the default policy as expected.

TAC said the RAT table supersedes LDAP, but if that was true my email should have hit that rule also. They also said it would not check LDAP without it set on the listener, but that is not true it would seem.

So,

1) I guess in what order does stuff get checked, does policy supersede RAT which supersedes LDAP?

2) How do I set the group check on the listener? I can select a query, but unlike a policy it doesn't have a spot to add the group.

2b) TAC said we have to call the group on the listener and also call the group in the mail policies, but policies are not listener specific.

2c) If it's just set on the listener, do I have to modify the query to the correct group? IE change 

(&(memberOf={g})(proxyAddresses=smtp:{a}))

to

(&(memberOf={CN=fg_External_Email_Access,OU=Domain,OU=Functional Groups,DC=MYCO,DC=COM})(proxyAddresses=smtp:{a}))

3)Where/what does the RAT table play in it, do we blank it out once we set LDAP?

My biggest issue is there really is no easy way to test global email settings without causing issues. We get over 150k/day incoming emails on 3 ESAs. So, if we mess it up we can mess up 1/3 of our emails. 

[Ken Stieers]

RAT and LDAP lookup on listeners is about ACCEPTING the mail into the work queue at all. Policy determination, even if it has LDAP lookups is separate.

1. Look in the online help for the Email Pipeline...
2. If you want to limit who you accept mail for AT ALL, you config the group in the accept query in System Administration/LDAP//Accept Query

2b. correct... they do different things

2c. yes, if you want to limit who you accept mail for AT ALL in your domain (but why??)

1. NO. See below.
RAT is what domains to we take mail for and if you need to tweak some things per domain (like do I want to lookup against the LDAP??)
LDAP is about stopping mail directory harvest attacks, what addresses are valid/not valid... e.g. you don't want your ESA processing mail for a@company.com, aa@company.com, aaa@company.com, etc...
Policy LDAP lookup is for things like mail to some addresses get treated differently (different security, different content policies, etc.)

[Dustin Anderson]

Yeah, this is the issue, we do limit who can be emailed as some email addresses are internal use only along with distribution lists.

And yeah, they used the RAT as the filter, there are over 6800 entries in the RAT currently for any email that can be accepted.

So, because of some internal only emails etc, they wan to have a FG or externally available email addresses and for the ESAs to check that instead of a manual RAT entries.

So, with that, do we leave the policies to any recipient, set the LDAP group query on the listener, and blank out the RAT table?

[Ken Stieers · Accepted solution]

Well I would have let exchange handle the internal only group thing with sender limitations, but since you want to do it on ESA...
I'd minimize the RAT to just the domain name, set LDAP accept query to the group you want...
If you do it that way, you need to do one other test: Send to an internal only address and an external allowed address in the same email.
If the external allowed address doesn't get it, you may have to do it using a policy to drop mail sent to internal only groups instead. I'm not sure if RAT or LDAP Accept cause splintering. (Splintering is when a mail is sent to multiple recipients, each one matches against policies separately)

[Dustin Anderson]

Thanks,

And yeah, I figured they should be able to do it in Exchange, but our admin didn't seem to know how so it looks to be falling to us to do their job.

[Ken Stieers]

PSSST.... Pass this to your exchange guys...
Get-DistributionGroup -identity |Set-DistributionGroup -RequireSenderAuthenticationEnabled $true