[Exchange 2K3] Permissions for Relay and Submit problem

Pagina: 1
Acties:

  • BlaaT0001
  • Registratie: September 2004
  • Laatst online: 12-01-2022
Situatie:

Binnen de organisatie waar ik stage loop zijn er twee verschillende groepen gebruikers te onderscheiden:
  • Groep 1: Gebruikers die zowel intern als extern mogen mailen.
  • Groep 2: Gebruikers die alleen intern mogen mailen.
Het moet voor Groep 2 niet mogelijk zijn de buitenwereld te bereiken vanuit Outlook. Tevens mogen zij ook geen externe e-mail ontvangen.

Er draait een Windows 2000 server met Exchange 2000 server. Momenteel met een redelijk standaard configuratie die alleen de mogelijkheden voor Groep 1 aanbiedt. Clients verbinden met de Exchange server middels Outlook / MAPI.
  • [Probleem 1: Gebruikers uit groep 2 mogen niet naar externe mailadressen mail kunnen sturen (mogen dus niet relayen).
  • Probleem 2: Gebruikers uit groep 2 mogen niet vanaf externe mailservers te bereiken zijn.]
Probleem 2 is gemakkelijk op te lossen door een subdomein aan te maken in de vorm “intern.domein.nl”. Dit interne domein wordt niet geadverteerd op het internet (geen MX record voor dit interne domein) en is voor externe mailservers dus niet te bereiken.

Probeem 1 heeft een minder makkelijke oplossing. Ik dacht dat de oplossing voor dit probleem zou liggen in de mogelijkheden om relaying voor de “Default Virtual SMTP server” te beperken.

Thuis heb ik een test Exchange 2003 sp1 op Windows 2K3 draaien om wat instellingen te testen.

De “Default Virtual SMTP Server” is de SMTP server waar externe mail op binnenkomt. “Anonymous Access” moet dus worden toegestaan anders komt externe mail niet meer binnen.
Naast “Anonymous Access” staat ook “Integrated Windows Authentication” aangevinkt om het voor Windows clients mogelijk te maken te “authenticaten” (als dit niet staat aangevinkt werkt mail verzenden vanuit Outlook nog steeds echter).

Bij Relay staan de volgende instellingen:
Aangevinkt: “Only the list below”-> Lijst is leeg
Uitgevinkt: “Allow all computers which successfully authenticate to relay regardless of the list above.

Users: Mail Submit Users met Submit rechten
Mail Relay Users met Submit en Relay rechten.

Via telnet maak ik een verbinding naar de Exchange server om het één en ander te testen.
Test 1: Proberen te relayen vanaf een extern subnet en vanaf een intern subnet.

Mail from: blaat@externdomein.nl
Rcpt to: blaat.externdomein.nl
550 5.7.1 Unable to relay for blaat@externdomein.nl

Mooi, ik ben dus geen Open Relay.

Test 2: Proberen te ontvangen vanaf een extern subnet en vanaf intern.

Mail from: blaat@externdomein.nl
Rcpt to: blaat@onsdomein.nl
250 2.1.5 blaat@onsdomein.nl

Mooi, ik ben dus bereikbaar vanaf externe mail servers.

Relayen kan nu dus alleen wanneer ik succesvol authenticate en lid ben van de groep “Mail Relay Users”. Dit is echter alleen het geval als ik een mail client gebruik die niet werkt met MAPI. Deze mail client maakt een SMTP verbinding met de Exchange server, authenticates met “Windows Integraded Authentication”, verstuurt via SMTP de mail naar de Exchange server, Exchange controleert of de gebruiker lid is van “Mail Relay Users” en relayed vervolgens het bericht naar de desbetreffende externe mailserver.

Via Outlook icm MAPI maakt het echter geen flikker uit of ik wel of niet lid ben van de groep “Mail Relay Users”. Zelfs als ik geen lid ben van “Mail Submit Users” of van “Mail Relay Users” kan ik gewoon mail versturen, intern en extern. Als in “netstat” gebruik tijdens het versturen van een e-mail zie ik ook dat er geen SMTP verbinding wordt gemaakt met de Exchange server vanaf de Outlook client. Via MAPI wordt de e-mail naar de Exchange server verstuurt, deze verstuurt de e-mail vervolgens (waarschijnlijk met de SMTP Virtual server) zonder de relay restricties in acht te nemen.

Kan iemand dit bevestigen? Weet iemand hoe ik dan een oplossing kan implementeren voor bovengenoemde problemen?

De Microsoft site en andere hulpsites helpen niet veel. Ook de help functie van Exchange schiet tekort. Er wordt nooit genoemd dat er met MAPI wordt gewerkt. Bij MS gaan ze er vanuit dat de mail via SMTP van Outlook/mailclient naar de Exchange server gaat en dat er geen gebruik wordt gemaakt van MAPI (of van OWA, zelfde resultaat als Outlook for that matter).

http://support.microsoft....aspx?scid=kb;en-us;818778

Bij voorbaat dank.

Groet,

BlaaT

BlaaT het niet dan SchaapT het niet!


  • Asteroid9
  • Registratie: Maart 2002
  • Laatst online: 00:51

Asteroid9

General Failure

Alles wat je via Mapi / Outlook aanroept trekt zich niks aan van SMTP cq relay permissions, dit draait onder de Exchange service account en niet onder de locally logged on user.
Een aparte SMTP server filtert normaliter alleen op IP adres dus je zal het op een ander niveau moeten zoeken.

Als je groep 2 een email adres toekent wat niet routeerbaar is (zelf verzonnen domein) zou mail naar buiten wel eens vanzelf gebounced kunnen worden, mail ontvangen kunnen ze dan in elk geval niet.
Misschien heb ik nog wel tijd over om even in mijn Exchange 2k3 testomgeving hier wat te rommelen, update volgt! :)

- = Simpele oplossingen zijn vaak vermomd als schier onoplosbare problemen.... = -


  • Asteroid9
  • Registratie: Maart 2002
  • Laatst online: 00:51

Asteroid9

General Failure

Je moet het inderdaad in de connectors zoeken.

Even quick en dirty opgezocht, maar dit zou moeten werken:

To block Internet send & receive in Exchange 2000:
1. Create and mail-enable a group called InternalOnly.
2. Create a recipient policy that gives them a fake SMTP address. i.e. @fake.domain. Leave the X400 address alone so they can receive internal mail. [Now they cannot receive mail from the outside] [1]
3. Drill down through Routing Groups > Group Name > Connectors > SMTP internet connector(s), choose its properties. Choose the Delivery Restrictions tab, and under "reject", add this group. Do this for each connector. [2]
4. Follow the steps in http://support.microsoft....spx?scid=kb;en-us;Q277872, regarding Connector Restrictions. [Now they can't use the SMTP connector(s) to send external mail]
5. Restart the SMTP service.

- = Simpele oplossingen zijn vaak vermomd als schier onoplosbare problemen.... = -