TCPAccess in MMP
Hi All (and Jay!),
We are going all ssl here for mail, but we have a few servers that will need to send and receive (IMAP) using non-ssl. So: I want to block non-ssl ports to our end users, but allow a handful of IPs to connect to 25 and 143. The MTA seems easy enough, given the PORTAccess directive, but I'm less clear on IMAP.
The TCPAccess directive in the ImapProxyAService.cfg is, I'm guessin, what one uses, but (as usual), the manuals don't mention that setting or how to use it. Can anyone point me to information or tell me how to include/exclude certain IP ranges from access to non-ssl ports?
We're running Sun Java System Messaging Server 6.2-3.04.
Thanks
Message was edited by:
LesliStClair
# 1
Something's not quite right, here."a few servers" need to access via IMAP? How is that? IMAP is for users to get their mail, not for servers to send it.Please help me to understand what it is you're really trying to do, here.jay
# 2
Apparently, per our DBAs, they have software that makes IMAP connections to the mail servers to pick up mail. Talk to Oracle. :) In any case, it doesn't matter that they're servers. I just need a way to include/exclude certain IPs from using the 143, non-ssl IMAP port through the MMP.
# 3
Ah. Ok.Hm. I don't think MMP has such a mechanism, to restrict by IP. However, if you can isolate the USER id, MMP can allow/disallow services by user attribute in LDAP....After all, IMAP is often used by the same user at different ip addresses. . .
# 4
OK, what's the procedure for limiting it by user id?
# 5
http://docs.sun.com/app/docs/doc/819-2657/6n4ub3hm2?a=viewThe ldap attribute is, mailAllowedServiceAccessFully documented in the Schema Reference, at the url above. . .
# 6
OK. I'll set that up.
But then what is TCPAccess for? The Admin guide (in the SMTP section) says, "If you wish to reject SMTP connections from certain IP address and you are using the MMP, you must use the TCPAccess option." Granted, I'm talking IMAP here, not SMTP, but that seems to indicate that access to the MMP can be controlled by IP. And wanting to restrict access to a service to local users by IP address doesn't seem to be such an odd request. For instance, I might prefer to force off-campus users to use our webmail, which would be a local connection.
# 7
TCPAccess in MMP is for the SMTP Proxy. There is exactly one reason to use the SMTP proxy, and that's to provide "POP before SMTP". for any other smtp use, you should be using the MTA instead.
If you want to restrict access to the MTA by ip, that's what your mappings file is for. By default, users outside your "internal_ip" range are required to authenticate in order to send mail outside your internal location.
# 8
I have the SMTP part set up. All traffic (except a handful of IPs) goes to encrypted 465 for SMTP.
The IMAP/MMP part , however... the link you gave me restricts access to IMAP/POP/HTTP, but not the way I'd like to. I don't want to prevent some users from using IMAP. I want to force nearly everyone to use SSL IMAP through the MMP. The other small group, that cannot use SSL for various reason now, would be the exception, still in the clear and going to 143 instead of 993.
# 9
MMP understands that "imap" is different from "imaps" So, you can prohibit users from using "imap", and allow them to use "imaps".
# 10
Yes, but I need control at the MMP level. The connection users make is to the MMP running on proxies; the proxies connect to the actual mailstores with plain-vanilla imap. Wouldn't that mean that all users are, as far as the mailstores are concerned, connecting with IMAP rather than IMAPS?
(BTW, we're doing it that way because they're all on a private VLAN, so we don't gain anything by encrypting the traffic.)
# 11
"I want to control this at the MMP level"."MMP understands the difference between "IMAP" and "IMAPS". . . Your configuration is typical, in having MMP communicate to the store un-encrypted. What I told you earlier is what you want to follow . .
# 12
Sorry, I misread. I'll give it a try.
# 13
Hi,
The general approach to using the MMP to restrict access is as follows:
-> lock down the back end stores to only allow connections from the MMP hosts, this stops people accessing the stores directly.
-> ./configutil -o service.imap.domainallowed -v 'imap:<MMP host>$imap:<MMP host>'
-> add mailallowedserviceaccess attribute to users directory entries
-> grant IMAP access to just those users who need it (e.g. oracle server user).
Regards,
Shane.
# 14
Hi Shane,
The lockdown is standard to our set up. I've done everything but the configutil change, and find I'm getting an error: Access to this service for user@mydomain denied from client address (*mailAllowedServiceAccess).
In the record, I have: mailAllowedServiceAccess: +imaps:*$-imap:*. I've also tried only +imaps:*.
Since the stores can't be accessed by anything but the proxies, is the configutil change necessary? Since I'd have to restart (and this is a clustered system) to get a configutail change to stick, I'd rather not make it if I don't have to.
(I assume the configutail change needs to be made on the stores rather than the proxies?)
Message was edited by:
LesliStClair
# 15
Seems to be working now. I think caching was the problem, given what I see in the mmp debug log.Thanks again!
# 16
Stopped working again, with the same error.
To review, I've added
mailAllowedServiceAccess: +imaps:*$pops:*
to a record. Login fails with Access to this service for user@mydomain.edu denied from client address (*mailAllowedServiceAccess)
So is the configutil change necessary?
# 17
The configutil setting is how to restrict access to the store to just the MMP. It doesn't sound like that's your problem.You will want to start examining logs, to see where the failure is happening. On the MMP, or on the store.
# 18
It's the mmp, I think (from the MMP's log):
...
20061024 134250 /opt/SUNWmsgsr/config/ImapProxyAService.cfg (sid 0x64f3d8) TCP Access denied for xxxx@ithaca.edu
20061024 134250 /opt/SUNWmsgsr/config/ImapProxyAService.cfg (sid 0x64f3d8) badguy 1xx.1xx.xxx.xxx now has 9 badness
# 19
At this point, it may be better for you to open a support case. I'm not really sure what you've set, nor what the problem is. I know that we've done this before, though.
# 20
Hi,
A support case is probably best.
I seem to remember like Jay that there are certain steps to getting this working correctly, such as adding the MMP's IP address to the rule itself e.g. +imap:MMP address otherwise when the MMP connects to the back-end store in clear text IMAP it fails.
Regards,
Shane.
# 21
Adding the IP was what I started trying this morning (though why * or ALL doesn't work is a mystery). There are potential cache issues, though, and I want to make sure that those aren't masking a problem (or a success).
I've found that +ALL:ALL works. Even +imap:* (or +imap:ALL) works. But +imaps:ALL doesn't. So I'm going to try +imaps:*$+imap:172.16.x.x (using the internal addresses of our proxies).
# 22
It looks like that was the solution:
to each user record, add:
mailallowedserviceaccess: +imaps:*$+imap:172.16.x.x,172.16.x.x
It makes sense. If the mailstore's imap checks the directory for allowed access, then imap (as opposed to imaps) has to be part of the list, with the proxies listed as the allowed clients.
I disabled caching for mmp and imap on the store, but there must be some other caching at work, too (directory?), because the change took a few minutes to propagate.
