WEBMAIL AUTHENTICATION PROBLEM

Please describe how you have set Astaro up to access OWA.
port forwards/NAT/etc....

I have the same problem but unfortunately I'm not able even to get the login request: the browser simply says that the requested server is not available.
Initially Exchange server had a public IP address chosen from a lot of 8 IPs assigned by the ISP. There was in place a 3com firewall appliance and OWA used to work well.
Then, after putting ASL in place, I configured a DMZ and the Exchange server external nic with an address of that subnet.
Again,  SMTP, windows update, antivirus update, browsing work pretty well. OWA not at all. The very unusual thing is that OWA doesn't work even if I try to connect from the Exchange server box itself!

I put in place all the following:

Definition --> Network
DMZ as 192.168.1.0/24
Internal as 192.168.0.0/24
External as 194.243.41.184/29
Posta 186 as 192.168.1.186 (SMTP server)
Posta 187 as 192.168.1.187 (SMTP server)
Web 187 as 192.168.1.187
(the previous three are actually the same Exchange server and it has two addresses on the same nic)
Virtual 186 as 192.168.1.186/32
Virtual 187 as 192.168.1.187/32

Network --> Nat/Masquerading
Masq_DMZ as
DMZ (network) --> all/all Masq_External None
Masq_Internal as
Internal (network) --> all/all Masq_External None
OWA as
all --> Virtual 187 (address) / HTTP None Web 187
Posta com as
all --> Virtual 187 (address) / HTTP None Posta 187
Posta net as
all --> Virtual 186 (address) / HTTP None Postal 186

Packet Filter rules
Source Any Service HTTP Allow Destintation Web 187
Source Any Service HTTPS Allow Destintation Web 187
Source Any Service SMTP Allow Destintation Posta 186
Source Any Service SMTP Allow Destintation Posta 187
Source DMZ (network) Service Any Allow Destintation Any
Source Internal (network) Service Any Allow Destintation Any
Source Any Service Any Drop Destination Any

HTTP Proxy
Status enable
Operation Mode Active Directory/NT Domain Membership
Log Level Access log
Anonymity Standard
Allowed networks Internal, DMZ
Content filter Enabled
Parent proxy Disabled
Caching Eanbled
Block Connect Method ... Disabled
Allowed Target Services DNS, FTP, FTP-control, HTTP, HTTPS, IDENT, LDAP_TCP, Microsoft SMB, SMTP, SQUID
TCP port 8080

That's all, I think. ASL version is 5.102. Windows server is SBS2003, totally updated.
Is there anyone who can help? (consider that this is my first experience with Linux).
Thank you in advance for your time.
Best regards.
Riccardo

I am not an expert on Exchange but your HTTP proxy Anonymity Standard setting may be causing some of the problem. 

I have a lite version of Desknow, a web based email server. Whenever I turn Anonymity to standard or parinoid the server throws internal server errors to the user trying to authenticate themselves - remotely or internally. This happens because some of the http headers that ASL strips for anonymity are needed by the server to correctly display the content based on the type of browser used.

It is just a thought, give it a try with Anonymity set to none.

I am not an expert on Exchange but your HTTP proxy Anonymity Standard setting may be causing some of the problem. 

I have a lite version of Desknow, a web based email server. Whenever I turn Anonymity to standard or parinoid the server throws internal server errors to the user trying to authenticate themselves - remotely or internally. This happens because some of the http headers that ASL strips for anonymity are needed by the server to correctly display the content based on the type of browser used.

It is just a thought, give it a try with Anonymity set to none.

Thank you Dayne1942 for your hint.
I tried but without success. I also changed the authetication mode from Active Directory/Nt Domain to none but no way.
Best regards.

You say OWA does not even work from the Exchange server itself?

Turn off proxy in IE and connect directly.  If this still does not work then the problem is your Exchange setup, not Astaro.

Thank you Simon Shaw for your advice. Nevertheless I don't believe that the Exchange setup has any problem because it used to work before the introduction of Astaro. In other words: if I exclude ASL and I change back only the IP (the IP + subnet mask + gateway, of course) of the Exchange Server to my public IP (and the one that the DNS records point to), OWA works again; when I put ASL on line again (and change the IP of the Exchange server to the one that I've assigned in the DMZ) OWA stops.
Thank you for your suggestion, anyway.
Best regards,

You are changing the IP of the Exchange server?  You seem to have 2 NIC's on the Exchange server, one with internal address and one with a DMZ address?  This is highly dangerous.

Suggest you do the following:

Put the Exchange server on your internal LAN, with one NIC with internal LAN address.

On Astaro, set a virtual interface using a public IP.
Port forward required ports to the internal IP of the Exchange server.

I assume you are using RPC over HTTPS  to connect to Exchange with a certificate installled on Exchange?

Your configuration seems overly complex and confusing [:)]

Having your Exchange server with 2 NIC's one internal and one on DMZ basically negates the firewall.  If someone can get access to Exchange they are into your internal LAN.

Highly recommend RPC over HTTPS.  You only need 1 port open then and it's all encrypted traffic.

Thank you Simon for your help.
I understand that our configuration is complex and confused because it is transitory. At the beginning our Exchange Server had a public address and also had the role of firewall and NAT router for the rest of our LAN. This is the reason of the two nics.
As soon as ASL will prove its capabilities, we'll have a definitive simplier configuration, with only one nic and the Exchange Server in our LAN.
I'll try the RPC over HTTPS.
Thank you and best regards,

If you require any help getting RPC over HTTP working let me know.  Exchange 2003 works fine behind Astaro, we have a similar setup at my work.

yup, I would be grateful if you could help me setting this up. Setup is as you sugested, one Exchange server with Internal IP behind ASL.  I suppose I need something like a port forward but the help file is silent on that.

Solution found: Setup DNAT rule. Open 443 to internal box.

But another question: In this setup, if exchange box is compromised, the intruder is in the internal LAN as well -  just like in the 2 NICs (DMZ, LAN) scenario. This sounds like a scenario that is very unsafe?

Thanks
Michael

Well yes... But at least you only have SSL open to it.
Exchange requires Active Directory, to get that working for a DMZ machine you need to open a whole bunch of ports.  (About a minimum of 8 and some are very exploitable)...

I tend to think a pinhole port forwarding encrypted SSL to Exchange is probably safer than having a machine in the DMZ with a foot in each network.

Thanks, I did not know how much you need to open up to get AD working - usually not my problem :-)

Maybe you have experience with the next problem in line: I got all the external clients to access OWA w/o problems. Now the SysAdmin tells me that internal clients should have access as well. Since some clients are Notebooks with access both from inside and outside, he needs the Macs to always be able to access the external IP of OWA that is DNATed to the internal Exchange (otherwise the Mac Clients would always re-syncronise because they do not know the internal and the external IP are the same machine). 

Do you know of any way to achieve that? Setting up a DNAT from the internal network to the internal NIC of ASL  (and then forward to internal Exchange) does not seem to work ..

Michael

Why would they resynch?

We use split DNS here. (Internal DNS and an External DNS).
the internal DNS points to the private IP of the Exchange server and the external DNS points to the public IP.  Works fine with no synch issues.

Unsure why you would get synch issue anyway...?

We don't use Macintosh's tho.  (First I thought you meant MAC address).

As far as I know you cannot DNAT like that from internally.  Ie go out then come back in... Doesn't work.