RE: OWA front end server - licensing and security
Hi Ed I think you'll find that I followed my initial post with an immediate follow up that stated: Sorry, I should have said that it eliminates any key-logging concerns related to authentication - it obviously can't stop the actual recording of keystrokes by key-logging software. It will however, basically eliminate the possibility of someone gaining access to your email system using credentials left behind by one of your users which is where we happen to draw the line in terms of functionality/security. Greg -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Friday, 19 September 2003 7:02 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Perhaps, but that's not what he said. Ed --- Steve Evans [EMAIL PROTECTED] wrote: It doesn't, but it keeps people from reusing credentials. At least I believe that's the posters point. Steve Evans SDSU Foundation -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 1:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I don't see how that would stop key-logging. Ed --- Greg Marr [EMAIL PROTECTED] wrote: We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA
RE: OWA front end server - licensing and security
Yeah, I remember them in my mainframe days, we used them for our remote access. Like'em, I thought they sold out. Cheers Paul Standards are like toothbrushes, everyone wants one but not yours -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: 19 September 2003 22:55 To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I couldn't tell you. Our dialup consists of dialing to what essentially is a world-wide ISP, then firing up a Nortel VPN client. The Nortel client is apparently pretty tightly integrated with SecurID - I'm assuming it uses the native SecurID API for authentication. I remember in the old days, when we used Shivas[1] for remote access we had the same problem. The Shivas were limited to using Tacacs to talk to SecurID. Tacacs didn't have provisions for querying the user for more information (next token, new PIN, etc), so these features didn't work. Then Shiva added Tacacs+, which DID allow for querying the user, and life was good. You will need to look at what protocol your authentication mechanism is using to talk to SecurID and see if you can come up with something that supports querying the user. [1] Anyone remember Shiva? I'm constantly amazed at how a company could literally own the remote access market, then manage to lose everything in such a short period of time. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:23 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ken / Roger, I know it's OT, but I have a quick question for you two. We don't have a VPN option here, but we have ~50 users using the tokens for dial-in. Occasionally, their tokens will get out of sync and of course, lock them out after three successive tries. As Ken indicated, if the user is two codes ahead or behind, it will put your token in Next-Token mode and is supposed to prompt you onscreen. However, our users never see the Next-Token notification on their end. Why? Is it because they are using Win9x/ME on their end or is it because of something on the server end? Server is NT 4 SP6a in an NT4 domain. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:54 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you
RE: OWA front end server - licensing and security
Intel bought them for next to nothing. -Original Message- From: Hurst, Paul [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 3:42 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Yeah, I remember them in my mainframe days, we used them for our remote access. Like'em, I thought they sold out. Cheers Paul Standards are like toothbrushes, everyone wants one but not yours -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: 19 September 2003 22:55 To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I couldn't tell you. Our dialup consists of dialing to what essentially is a world-wide ISP, then firing up a Nortel VPN client. The Nortel client is apparently pretty tightly integrated with SecurID - I'm assuming it uses the native SecurID API for authentication. I remember in the old days, when we used Shivas[1] for remote access we had the same problem. The Shivas were limited to using Tacacs to talk to SecurID. Tacacs didn't have provisions for querying the user for more information (next token, new PIN, etc), so these features didn't work. Then Shiva added Tacacs+, which DID allow for querying the user, and life was good. You will need to look at what protocol your authentication mechanism is using to talk to SecurID and see if you can come up with something that supports querying the user. [1] Anyone remember Shiva? I'm constantly amazed at how a company could literally own the remote access market, then manage to lose everything in such a short period of time. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:23 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ken / Roger, I know it's OT, but I have a quick question for you two. We don't have a VPN option here, but we have ~50 users using the tokens for dial-in. Occasionally, their tokens will get out of sync and of course, lock them out after three successive tries. As Ken indicated, if the user is two codes ahead or behind, it will put your token in Next-Token mode and is supposed to prompt you onscreen. However, our users never see the Next-Token notification on their end. Why? Is it because they are using Win9x/ME on their end or is it because of something on the server end? Server is NT 4 SP6a in an NT4 domain. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:54 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication
RE: OWA front end server - licensing and security
As currently designed, it requires a third party LEAP client be installed, on top of the wiredless client needed for the card and any other necessary software. Not high on my favorites list right now.. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:43 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security S!! Our security folks wanted SecurID for wireless, but we managed to talk them into just a userid/passwd. We told them NO ONE ELSE was using SecurID for wireless... -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 1:54 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again
RE: OWA front end server - licensing and security
It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I don't see how that would stop key-logging. Ed --- Greg Marr [EMAIL PROTECTED] wrote: We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests
RE: OWA front end server - licensing and security
Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. snip _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. snip _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. snip _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. snip _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web
RE: OWA front end server - licensing and security
Ken / Roger, I know it's OT, but I have a quick question for you two. We don't have a VPN option here, but we have ~50 users using the tokens for dial-in. Occasionally, their tokens will get out of sync and of course, lock them out after three successive tries. As Ken indicated, if the user is two codes ahead or behind, it will put your token in Next-Token mode and is supposed to prompt you onscreen. However, our users never see the Next-Token notification on their end. Why? Is it because they are using Win9x/ME on their end or is it because of something on the server end? Server is NT 4 SP6a in an NT4 domain. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:54 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger
RE: OWA front end server - licensing and security
S!! Our security folks wanted SecurID for wireless, but we managed to talk them into just a userid/passwd. We told them NO ONE ELSE was using SecurID for wireless... -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 1:54 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's displaying on the token, it's good for 1 minute with a 1 minute latency period. If you don't enter the number while it's viewable, then you've missed your window of opportunity, because it was only good for one minute. Oh and BTW...if you are trying to guess the code and miss it three times, regardless of length of time between guesses, it will lock your token until an admin can reset it. That's how I understand the process. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 5:44 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It doesn't stop key logging per se, but it renders it ineffective. The SecurID tokens use a three factor[1] authentication system, in which the third piece is a 6 digit, one time use code. That code is good for exactly 3 minutes, and once used cannot be used again. Therefore, logging the authentication process is useless, as you'll only get 2 of the 3 factors, and for the third factor, you have a 1 in 1,000,000 chance, reset every three minutes, to guess that last part. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] They call it 2 factor, but you need a username, a PIN, and the securID token number to log in - that's either 3 or 11, depending on how much of a geek you are. snip _ List posting FAQ: http://www.swinc.com
RE: OWA front end server - licensing and security
I couldn't tell you. Our dialup consists of dialing to what essentially is a world-wide ISP, then firing up a Nortel VPN client. The Nortel client is apparently pretty tightly integrated with SecurID - I'm assuming it uses the native SecurID API for authentication. I remember in the old days, when we used Shivas[1] for remote access we had the same problem. The Shivas were limited to using Tacacs to talk to SecurID. Tacacs didn't have provisions for querying the user for more information (next token, new PIN, etc), so these features didn't work. Then Shiva added Tacacs+, which DID allow for querying the user, and life was good. You will need to look at what protocol your authentication mechanism is using to talk to SecurID and see if you can come up with something that supports querying the user. [1] Anyone remember Shiva? I'm constantly amazed at how a company could literally own the remote access market, then manage to lose everything in such a short period of time. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:23 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ken / Roger, I know it's OT, but I have a quick question for you two. We don't have a VPN option here, but we have ~50 users using the tokens for dial-in. Occasionally, their tokens will get out of sync and of course, lock them out after three successive tries. As Ken indicated, if the user is two codes ahead or behind, it will put your token in Next-Token mode and is supposed to prompt you onscreen. However, our users never see the Next-Token notification on their end. Why? Is it because they are using Win9x/ME on their end or is it because of something on the server end? Server is NT 4 SP6a in an NT4 domain. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:54 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer valid, as the timestamp when you entered it will no longer match with the timestamp on the server for when that code was valid. So the short version is that if you enter the code while it's
RE: OWA front end server - licensing and security
Thanks Ken. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:55 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I couldn't tell you. Our dialup consists of dialing to what essentially is a world-wide ISP, then firing up a Nortel VPN client. The Nortel client is apparently pretty tightly integrated with SecurID - I'm assuming it uses the native SecurID API for authentication. I remember in the old days, when we used Shivas[1] for remote access we had the same problem. The Shivas were limited to using Tacacs to talk to SecurID. Tacacs didn't have provisions for querying the user for more information (next token, new PIN, etc), so these features didn't work. Then Shiva added Tacacs+, which DID allow for querying the user, and life was good. You will need to look at what protocol your authentication mechanism is using to talk to SecurID and see if you can come up with something that supports querying the user. [1] Anyone remember Shiva? I'm constantly amazed at how a company could literally own the remote access market, then manage to lose everything in such a short period of time. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:23 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ken / Roger, I know it's OT, but I have a quick question for you two. We don't have a VPN option here, but we have ~50 users using the tokens for dial-in. Occasionally, their tokens will get out of sync and of course, lock them out after three successive tries. As Ken indicated, if the user is two codes ahead or behind, it will put your token in Next-Token mode and is supposed to prompt you onscreen. However, our users never see the Next-Token notification on their end. Why? Is it because they are using Win9x/ME on their end or is it because of something on the server end? Server is NT 4 SP6a in an NT4 domain. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:54 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security It really is a cool system. We're currently using it for VPN access and front ending OWA, and we're playing with it and some Cisco Aironet wireless devices - requiring SecurID authentication before you get onto the wireless network. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 2:21 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I've not examined the system for several years (I'm just a happy user now, not and admin), but at least at one time SecurID would accept the current code (of course),one code behind or one ahead for a total window of 3 minutes as Roger notes. If the gadget's clock had drifted to more than one minute off, and you were TWO codes ahead or behind, the system would additionally prompt for the NEXT code displayed to make sure you were you, and it would update the stored time offset for your gadget. Pretty slick system. -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:01 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Actually, you've got the system down correctly. However, the slack time is +/- 1 minute, so you really get 3 minutes per code. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Blunt, James H (Jim) [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:29 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Forgive me for arguing, but I believe the time alloted for guessing that third factor is even less than indicated below. Of course, by token, I am referring to what RSA calls a keyfob. Is that what you are referring to as well? Here is what I understand to be the process, from reading the manuals we have: 1. Upon issuance to the user, you synch the token/keyfob with the the RSA server DB. 2. A 6-digit code displays for 1 minute on the token. 3. If used for authentication within that 1 minute period, it is time-stamped as to when you entered the Passcode (PIN + code) and has an additional 1 minute latency period. Meaning that if you dial-up and enter your passcode, 30-seconds into the code, you have 1:30 to connect to the dial-up server and be authenticated. 4. If you enter the same code after the display has rolled over however, that code is no longer
RE: OWA front end server - licensing and security
Another option is an SSL based VPN, there is no client software to install and you can users can get access to your 'internal' OWA server from any web browser, public terminals included. Several companies make them, we have one from Neoteris installed. It works great, we use an RSA ACE server for authentication as well which I would strongly recommend. But it gives your users access to their email via OWA from just about _any_ web browser they can find. No client, no setup for the end user and it will never be blocked by any ISP since its SSL. Ed -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 8:07 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting
RE: OWA front end server - licensing and security
Actually, we use squid and OpenBSD for just that purpose, and I don't recall falling into the issue with the absolute URLs, though. It might be because squid is rewriting the URLs on their way through - its been a year since we set it up and we haven't had to touch it since.. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -Original Message- From: Ken Cornetet [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 5:30 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We use a Network Appliance NetCache in the DMZ as a reverse proxy SSL front end. Internet OWA users hit the NetCache with HTTPS, and the NetCache decrypts and forwards HTTP to a front-end server. Works great, but was a little pricey. Also, because OWA likes to send out absolute URLs, there is a widget you have to install in IIS on the front-end server that makes it change the outputted URLS from http: to https:. This has the side effect of making that front-end server unusable from inside traffic. Come to think of it, I guess you could add another OWA virtual site and not install the widget on it. Untested. If the NetCache is too pricey for you, and you've got someone with unix experience, you can do much the same thing with squid on linux or BSD. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 6:05 PM To: Exchange Discussions Subject: OWA front end server - licensing and security I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode= lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
If you can't risk the data getting out, then break your Internet connection. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can === message truncated === __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use
RE: OWA front end server - licensing and security
I don't see how that would stop key-logging. Ed --- Greg Marr [EMAIL PROTECTED] wrote: We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley === message truncated
RE: OWA front end server - licensing and security
It doesn't, but it keeps people from reusing credentials. At least I believe that's the posters point. Steve Evans SDSU Foundation -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 1:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I don't see how that would stop key-logging. Ed --- Greg Marr [EMAIL PROTECTED] wrote: We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN
RE: OWA front end server - licensing and security
Perhaps, but that's not what he said. Ed --- Steve Evans [EMAIL PROTECTED] wrote: It doesn't, but it keeps people from reusing credentials. At least I believe that's the posters point. Steve Evans SDSU Foundation -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 1:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security I don't see how that would stop key-logging. Ed --- Greg Marr [EMAIL PROTECTED] wrote: We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson === message truncated === __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http
RE: OWA front end server - licensing and security
You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] # Notice: This e-mail message is only intended to be read by the named recipient. It may contain information which is confidential, proprietary or the subject of legal privilege. If you are not the intended recipient please notify the sender immediately and delete this e-mail. You may not use any information contained in it. Legal privilege is not waived because you have read this e-mail. For further information on the Beca Group of Companies, visit our web page http://www.beca.co.nz # _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
Yeah, but you can easily specify that only the front-end server could use those ports. Sincerely, Andrey Fyodorov Systems Engineer Messaging and Collaboration Spherion -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 7:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
IPSec is a nice idea too. But you need to test test test. Sincerely, Andrey Fyodorov Systems Engineer Messaging and Collaboration Spherion -Original Message- From: Leeann McCallum [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 7:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] # Notice: This e-mail message is only intended to be read by the named recipient. It may contain information which is confidential, proprietary or the subject of legal privilege. If you are not the intended recipient please notify the sender immediately and delete this e-mail. You may not use any information contained in it. Legal privilege is not waived because you have read this e-mail. For further information on the Beca Group of Companies, visit our web page http://www.beca.co.nz # _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] # Notice: This e-mail message is only intended to be read by the named recipient. It may contain information which is confidential, proprietary or the subject of legal privilege. If you are not the intended recipient please notify the sender immediately and delete this e-mail. You may not use any information contained in it. Legal privilege is not waived because you have read this e-mail. For further information on the Beca Group of Companies, visit our web page http://www.beca.co.nz # _ List posting FAQ: http://www.swinc.com
RE: OWA front end server - licensing and security
We use a Network Appliance NetCache in the DMZ as a reverse proxy SSL front end. Internet OWA users hit the NetCache with HTTPS, and the NetCache decrypts and forwards HTTP to a front-end server. Works great, but was a little pricey. Also, because OWA likes to send out absolute URLs, there is a widget you have to install in IIS on the front-end server that makes it change the outputted URLS from http: to https:. This has the side effect of making that front-end server unusable from inside traffic. Come to think of it, I guess you could add another OWA virtual site and not install the widget on it. Untested. If the NetCache is too pricey for you, and you've got someone with unix experience, you can do much the same thing with squid on linux or BSD. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 6:05 PM To: Exchange Discussions Subject: OWA front end server - licensing and security I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
I've been thinking a lot about this, and decided to go with another approach. I'm going to create another network, connected to the Exchange server, and allow clients to VPN into that network. It doesn't have access to any other resources, and is empty except for OWA (for now anyway). And no front end server. Our load doesn't justify a front end server, and the security benefits don't seem large enough to justify the expense. But the IPSec idea is a good one. And, as I remember, you can place a lot of restrictions on IPSec. Thanks for the suggestions, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Fyodorov, Andrey Sent: Wednesday, September 17, 2003 6:30 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security IPSec is a nice idea too. But you need to test test test. Sincerely, Andrey Fyodorov Systems Engineer Messaging and Collaboration Spherion -Original Message- From: Leeann McCallum [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 7:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode= lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] # Notice: This e-mail message is only intended to be read by the named recipient. It may contain information which is confidential, proprietary or the subject of legal privilege. If you are not the intended recipient please notify the sender immediately and delete this e-mail. You may not use any information contained in it. Legal privilege is not waived because you have read this e-mail. For further information on the Beca Group of Companies, visit our web page
RE: OWA front end server - licensing and security
I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode= lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=; lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] # Notice: This e-mail message is only intended to be read by the named recipient. It may contain information which is confidential, proprietary
RE: OWA front end server - licensing and security
ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode= lang =english
RE: OWA front end server - licensing and security
We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server
RE: OWA front end server - licensing and security
We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you
RE: OWA front end server - licensing and security
Sorry, I should have said that it eliminates any key-logging concerns related to authentication - it obviously can't stop the actual recording of keystrokes by key-logging software. It will however, basically eliminate the possibility of someone gaining access to your email system using credentials left behind by one of your users which is where we happen to draw the line in terms of functionality/security. Greg -Original Message- From: Greg Marr Sent: Thursday, 18 September 2003 11:31 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We have set up our OWA to require two-factor authentication (SecurID) which eliminates any key-logging concerns but this system is not cheap at approx $300 AU ($160 US) per user. The upside is that you can use the same system to authenticate all of your remote access users (dial-up, VPN, etc) and this is the function that really allows me to sleep well at night. I guess that it all depends on how many people are going to require this functionality and of course, your budget. Greg -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 10:07 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security We talked about this exact scenario. We decided that given how easy it is to install a key logger, and other malware, on public systems we decided it was too risky. We are planning on using public folders quite heavily with data that we can't risk getting out. Same with the address books. We are trying to figure out a way to give people access to email only from a public terminal. No public folders or address books. If you have any suggestions, that would be great. Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Wednesday, September 17, 2003 4:40 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security ISA is a better solution in a DMZ because it doesn't require the plethora of holes in the internal firewall. http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechnol/isa/deploy/isaexch.asp Requiring VPN (your other message) is a good idea, however, you may be coming back to ISA or some other idea when your users demand to be able to get e-mail from a coffeehouse kiosk terminal. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I have to admit to being a little confused, how would ISA help, aside from being a proxy? Which isn't nothing, but I'm wondering if I'm missing something else. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Webb, Andy Sent: Wednesday, September 17, 2003 7:04 AM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Don't forget you also have to fully protect the front end server from all the other servers on the DMZ from which it is not isolated. Those other systems may have been placed on the DMZ in an insecure state with the thought that if anyone broke them, they would be isolated from the internal LAN. What happens when you put the FE in the DMZ is you break that theory. The DMZ is no longer isolated from the LAN. You definitely have to secure the FE, but once you have, why not put it inside where it is not at risk from questionable systems on the DMZ? Better to put an ISA server in the DMZ as was suggested earlier. Regarding IPSEC, Exchange 2003 explicitly states that IPSEC is now supported between front end and back end. So if you upgrade, that's perhaps an option. Though a lesser one than using ISA imho. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leeann McCallum Sent: Tuesday, September 16, 2003 6:32 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security You could throw an OWA front end server in the DMZ, put certificate on as Ed suggests, and then wrap everything up in an IPSEC packet that goes between the front end and backend. Between the client on the net and the front end, you would use SSL, so just open 443. -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2003 11:29 a.m. To: Exchange Discussions Subject: RE: OWA front end server - licensing and security Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server
Re: OWA front end server - licensing and security
Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
That's exactly what I'm saying. Get the publications and read what ports you must open and if that doesn't scare you, nothing will. Open only port 443 for SSL OWA, and only if you can't require a VPN. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
Ok, I see what you're saying. What are the security benefits to having a front end server inside of the LAN, as opposed to opening port 443 on the primary Exchange server? It seems to me if the front end server is compromised, then your primary Exchange server is just as vulnerable. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:41 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security That's exactly what I'm saying. Get the publications and read what ports you must open and if that doesn't scare you, nothing will. Open only port 443 for SSL OWA, and only if you can't require a VPN. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: OWA front end server - licensing and security
There isn't a whole lot of security benefit except that an attacker can't touch the Exchange back-end server directly. But the front-end-back-end architecture has never really been about security. He'd have to compromise the front-end server by breaking through your SSL security, then his agent would have to attack something else. A front-end server handles all the OWA transactions; it doesn't pass the session off to the back-end and instead proxys the transactions. I think the risk is pretty small with a properly secured OWA front-end server. If you really want a box in the DMZ, use an ISA server there to publish OWA. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: Ok, I see what you're saying. What are the security benefits to having a front end server inside of the LAN, as opposed to opening port 443 on the primary Exchange server? It seems to me if the front end server is compromised, then your primary Exchange server is just as vulnerable. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:41 PM To: Exchange Discussions Subject: RE: OWA front end server - licensing and security That's exactly what I'm saying. Get the publications and read what ports you must open and if that doesn't scare you, nothing will. Open only port 443 for SSL OWA, and only if you can't require a VPN. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: Ed, I'm a little confused. You're recommending that I put in a front end server, but not in the DMZ? It seems to me that I might have to open a bunch of ports, but if the front end server is in the LAN, all ports are by default open. Just to clarify, I have one Exchange server which lives on my LAN, and there is an SMTP server in my DMZ that relays messages to the Exchange server. At the moment, I don't have any other Exchange servers running. Thanks, Erick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Crowley Sent: Tuesday, September 16, 2003 4:25 PM To: Exchange Discussions Subject: Re: OWA front end server - licensing and security Instal a certificate on the front-end server and open port 443 to the front-end server. Putting a front-end server in a DMZ requires you to open lots of dangerous ports through the internal firewall to the Exchange servers, DCs and GCs. Ed --- Erick Thompson [EMAIL PROTECTED] wrote: I'm setting up OWA in my organization, and I have two choices. I can set up Exchange on the web server (in the DMZ), and specify it as a front end server, or I can open port 80 to the primary Exchange server. From a security standpoint, I really like the first option, but I'm thinking that I need a second Exchange Enterprise license. Am I correct in this? Am I being too paranoid about opening port 80 through to the internal Exchange server? I've never liked the idea of raw traffic entering my LAN Thanks, Erick _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchanget ext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchangetext_mode=lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL
