none
Understanding Recieve connectors and authentication - Exchange 2007 RRS feed

  • Question

  • Looking at current setup we have 3 recieve connectors:-

    Client 1 - All IP Port 587, Recieve mail from all IP, Authentication set to TLS, Basic, Windows

    Default 1 - All IP Port 25, Recieve mail all IP, Authtiction TLS, Basic, Exchange Server, Windows

    ABC 1 - All IP Port 25, Recieve mail has got a list of IPs, Authentication nothing selected.

    I know we've got lots of apps on servers that use Exchange. These are the ones listed in ABC 1.

    But know we've got an app on a server that HAS to use authentication. I've added the IP into ABCs list but it fails.

    How does an app know which recieve connector to use? Assuming its failing because its trying to use the ABC1 connector which is expecting no authentication but the app is trying to use username/password? If so, do I just need a new connector that does expect windows authentication?

    If so, why doesnt it use DEFAULT 1?

    Monday, October 5, 2015 1:06 PM

Answers

  • It fails on ABCs list because of the authentication, as you surmised.  And only the ABC connector will handle it, since its IP address is on the ABC connector.  The connector that most closely handles the IP address of the sending system will be the one that is used, regardless of how authentication is configured (on either the connector on the sending system).

    I'll let you know what we have and you determine how you want to handle your connectors.  We have a connector for each application or server type that connects to our system.  So we have a connector for all non-application Unix servers, and one for Application A and another for Application B (etc).  This way, if we have an application that misbehaves, we can shut it down without affecting any other application.  And we've blocked all traffic from our client workstation subnets on our default connectors.  (The Client <servername> connectors are therefore woefully underutilized.)

    And before you say, "Well, that's going to be a lot of receive connectors, isn't it?", yes, it is - each of our ten multi-role servers has 193 connectors so far.  I'm sure that many are rarely used, but our systems are safer this way.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    • Proposed as answer by David M (LePivert) Monday, October 5, 2015 5:48 PM
    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Monday, October 5, 2015 1:47 PM
  • Exchange uses the most restrictive connector to handle and SMTP traffic.  So if you have a connector with a range of 0.0.0.0/0 (your default receive connector), another with a range of 192.168.243.0/24, and a final one with the single IP address 192.168.243.17, and you have two servers, 192.168.243.29 and 192.168.243.17 that are sending, the first will always only be handled by the second connector, and the second will always only ever be handled by the third.  If you try to manually add that specific IP address to any other receive connector, your attempt will fail. This all happens before any consideration of authentication is taken into account.  Use this to figure out what connector is attempting to handle your external connections.

    Yes, you can remove it from your ABC connector, but I'd create a new connector just for it.

    And yes, you can modify connectors on the fly without requiring a service restart.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })



    • Edited by Will Martin, PFE Monday, October 5, 2015 2:44 PM
    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Monday, October 5, 2015 2:42 PM
  • Unless we can go back to your original configuration and test the system, I'm not going to be able to explain why the original settings didn't work.  I can think of a number of reasons, but they'd all be shots in the dark at this point.

    That being said, if I were you, I'd still determine if you really need your default receive connector open to all IP addresses.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Tuesday, October 6, 2015 1:32 PM

All replies

  • It fails on ABCs list because of the authentication, as you surmised.  And only the ABC connector will handle it, since its IP address is on the ABC connector.  The connector that most closely handles the IP address of the sending system will be the one that is used, regardless of how authentication is configured (on either the connector on the sending system).

    I'll let you know what we have and you determine how you want to handle your connectors.  We have a connector for each application or server type that connects to our system.  So we have a connector for all non-application Unix servers, and one for Application A and another for Application B (etc).  This way, if we have an application that misbehaves, we can shut it down without affecting any other application.  And we've blocked all traffic from our client workstation subnets on our default connectors.  (The Client <servername> connectors are therefore woefully underutilized.)

    And before you say, "Well, that's going to be a lot of receive connectors, isn't it?", yes, it is - each of our ten multi-role servers has 193 connectors so far.  I'm sure that many are rarely used, but our systems are safer this way.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    • Proposed as answer by David M (LePivert) Monday, October 5, 2015 5:48 PM
    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Monday, October 5, 2015 1:47 PM
  • It fails on ABCs list because of the authentication, as you surmised.  And only the ABC connector will handle it, since its IP address is on the ABC connector.  The connector that most closely handles the IP address of the sending system will be the one that is used, regardless of how authentication is configured (on either the connector on the sending system).

    I'll let you know what we have and you determine how you want to handle your connectors.  We have a connector for each application or server type that connects to our system.  So we have a connector for all non-application Unix servers, and one for Application A and another for Application B (etc).  This way, if we have an application that misbehaves, we can shut it down without affecting any other application.  And we've blocked all traffic from our client workstation subnets on our default connectors.  (The Client <servername> connectors are therefore woefully underutilized.)

    And before you say, "Well, that's going to be a lot of receive connectors, isn't it?", yes, it is - each of our ten multi-role servers has 193 connectors so far.  I'm sure that many are rarely used, but our systems are safer this way.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    Will. Yes - you're way seems the most sensible and easy to control I must admit.

    What I still don't understand though. For Default 1, 0.0.0.0-255 are listed but only specific IPs for ABC 1 so surely both match the criteria? So how does it know which one? What if IP addresses are listed for two connectors - how does that work?

    Is there any way to tell which connector an inbound connection is trying to use?

    Could I remove this explicit IP from ABC1 so its forced to use default then? It would work then wouldnt it because Default has got windows authentication enabled?

    Finally, can I add/amend these connectors on the fly with no restart of anything needed?

    Monday, October 5, 2015 2:29 PM
  • Exchange uses the most restrictive connector to handle and SMTP traffic.  So if you have a connector with a range of 0.0.0.0/0 (your default receive connector), another with a range of 192.168.243.0/24, and a final one with the single IP address 192.168.243.17, and you have two servers, 192.168.243.29 and 192.168.243.17 that are sending, the first will always only be handled by the second connector, and the second will always only ever be handled by the third.  If you try to manually add that specific IP address to any other receive connector, your attempt will fail. This all happens before any consideration of authentication is taken into account.  Use this to figure out what connector is attempting to handle your external connections.

    Yes, you can remove it from your ABC connector, but I'd create a new connector just for it.

    And yes, you can modify connectors on the fly without requiring a service restart.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })



    • Edited by Will Martin, PFE Monday, October 5, 2015 2:44 PM
    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Monday, October 5, 2015 2:42 PM
  • Exchange uses the most restrictive connector to handle and SMTP traffic.  So if you have a connector with a range of 0.0.0.0/0 (your default receive connector), another with a range of 192.168.243.0/24, and a final one with the single IP address 192.168.243.17, and you have two servers, 192.168.243.29 and 192.168.243.17 that are sending, the first will always only be handled by the second connector, and the second will always only ever be handled by the third.  If you try to manually add that specific IP address to any other receive connector, your attempt will fail. This all happens before any consideration of authentication is taken into account.  Use this to figure out what connector is attempting to handle your external connections.

    Yes, you can remove it from your ABC connector, but I'd create a new connector just for it.

    And yes, you can modify connectors on the fly without requiring a service restart.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })



    Thanks again Will. That makes sense.

    I think I need a new connector with just this one IP listed with the authentication I need. (Although I need to remove specific IP from ABC 1 dont I? Otherwise it wont let me create new?)

    So if I want to authenticate using domain logon/password for the email address in question, what authentication would I need? Would that be TLS and domain level?


    • Edited by paulfoel Monday, October 5, 2015 2:50 PM
    Monday, October 5, 2015 2:49 PM
  • You will need to remove it from ABC before you can place it on its own connector, yes.  As for your authentication, it's going to depend on what your sending application uses.  Most often, TLS is used (we have none that use anything else), but if your application uses MAPI, it might use Windows authentication.

    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    Monday, October 5, 2015 3:05 PM
  • Set up new connector with just one specific IP address. Added just basic authentication and it works OK.

    What I don;t understand is:-

    - This IP was not on the list of IPs for ABC1.

    - Since default contains a catch-all it would have used this one.

    - Default contains basic as one of the authentication methods ticked.

    So why didnt this work? Or is it because it was expecting ONLY basic not all the others?


    • Edited by paulfoel Tuesday, October 6, 2015 12:53 PM
    Tuesday, October 6, 2015 12:51 PM
  • Unless we can go back to your original configuration and test the system, I'm not going to be able to explain why the original settings didn't work.  I can think of a number of reasons, but they'd all be shots in the dark at this point.

    That being said, if I were you, I'd still determine if you really need your default receive connector open to all IP addresses.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    • Marked as answer by paulfoel Wednesday, October 7, 2015 8:49 AM
    Tuesday, October 6, 2015 1:32 PM