Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

In our exchange 2010 environment when setting up Outlook with one of the mailbox accounts, check name resolves the FQDN of our Client Access Server. We do not want employees/customers to see this information. I have a subdomain whos name record is pointed at the CAS server, so all is great until you hit the "check name" button during setup and it resolves to the FQDN of the server.

exchange.mysite.com turns to EX-CAS01.mysite.local alt text

I am trying to figure out how to keep this from happening because it doesn't look as good, but more importantly for security purposes.

share|improve this question
3  
security through obscurity is not really security –  Zypher Sep 9 '10 at 21:20
    
I can't think of anything insecure about knowing the server name. It's childishly easy to find out anyway. Hell, Outlook will even tell you.... –  Ben Pilbrow Sep 9 '10 at 21:28

2 Answers 2

up vote 3 down vote accepted

You can get around this by setting up a singe server CAS Array if that's what you really want to do.

Create a DNS entry for exchange.mysite.com on your internal DNS server and point it to your Exchange server. Then do this:

New-ClientAccessArray –Name “CAS Array” –Fqdn “exchange.mysite.com” –Site “Default-First-Site-Name”
Set-MailboxDatabase DatabaseName -RpcClientAccessServer “exchange.mysite.com”

You may even be able to get that to work without the CAS Array part, I just haven't tried it and probably wouldn't recommend it as Microsoft probably wont' support it.

share|improve this answer
    
I will put a caveat of I haven't tested this on this, but can't you just nslookup the CAS Array and it will return the FQDNs of the servers in the array? –  Ben Pilbrow Sep 9 '10 at 21:47
    
@Ben - If it's a C Record, yes. If it's an A record, no. If there's reverse DNS lookup, one could lookup the A record for exchange.mysite.com and then lookup the IP address that's returned. That could be fixed by changing the PTR record. –  Jason Berg Sep 9 '10 at 22:00

That looks normal to me. That field will resolve to the internal NetBIOS or FQDN of the server, not the public FQDN of the server (to which the SSL certificate is bound). I don't think there's anything that can be done about it. What is it about it that makes you think it's a security risk? How does knowing the internal name expose the server or client to any risk?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.