User account cannot open shared calendar

Al-MacLean · Post by **Al-MacLean** » Tue Jul 14, 2015 5:07 am

We're just migrating from an old Exchange 2003 server to 8.6 OSE. Have applied the cumulative patch (patch 3) as well. Up and running (first day of real users).
One user has found that she cannot view or open any shared folders; when clicking the Accept option in the share email notification, she just gets a Permission Denied error, but no details.
When trying to view the list of available shares, she sees nothing (of any type). I get the same result when viewing her account via the Admin option (View Mail).
I would prefer not to delete and recreate her account if at all possible - does anyone know if there is a way I can "reset" her permissions, or any other suggestions to check what might be wrong?
Thanks in advance - Alec

Gren Elliot · Post by **Gren Elliot** » Tue Jul 14, 2015 5:13 am

Is there any logging (for instance in mailbox.log) for this? May be worth increasing the logging level for the user.
Use something like:
zmprov addAccountLogger ann@example.com zimbra.soap TRACE

Al-MacLean · Post by **Al-MacLean** » Tue Jul 14, 2015 5:39 am

Hi Gren,

Yes, there is logging showing the permission error in the mailbox.log file.
(I should point out I'm a Linux noob so please bear with me in terms of anything stupid I mention!)

The log seems quite extensive, but the relevant part starts with:

2015-07-14 11:27:32,378 INFO [qtp509886383-190589:https://10.0.0.19:8443/service/soap/Cre ... intRequest] [name=sarah.meacham@copeohs.com;aname=admin@copeohs.com;mid=38;ip=10.0.0.41;ua=ZimbraWebClient - FF39 (Win)/8.6.0_GA_1178$
com.zimbra.common.service.ServiceException: permission denied: you do not have sufficient permissions
ExceptionId:qtp509886383-190589:https://10.0.0.19:8443/service/soap/Cre ... 7662d350ac
Code:service.PERM_DENIED

and then provides a large block of "at" messages like:

at com.zimbra.common.service.ServiceException.PERM_DENIED(ServiceException.java:290)
at com.zimbra.cs.mailbox.Mailbox.checkAccess(Mailbox.java:2620)
at com.zimbra.cs.mailbox.Mailbox.getItemById(Mailbox.java:2774)
at com.zimbra.cs.mailbox.Mailbox.getItemById(Mailbox.java:2765)
at com.zimbra.cs.mailbox.Mailbox.getFolderById(Mailbox.java:3903)
at com.zimbra.cs.mailbox.Mailbox.getFolderTree(Mailbox.java:4057)
at com.zimbra.cs.service.mail.GetFolder.handle(GetFolder.java:113)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:569)
at com.zimbra.soap.DocumentHandler.proxyRequest(DocumentHandler.java:555)
at com.zimbra.soap.DocumentHandler.proxyRequest(DocumentHandler.java:493)
at com.zimbra.cs.service.mail.CreateMountpoint.fetchRemoteFolder(CreateMountpoint.java:136)

Does any of this make help diagnosis?

Alec

Al-MacLean · Post by **Al-MacLean** » Tue Jul 14, 2015 5:40 am

If I added that provision setting, what file would it create and where?

Al-MacLean · Post by **Al-MacLean** » Tue Jul 14, 2015 6:55 am

I have found that creating a new share for this user just now still works.

But it's strange that the ones already issued that include her (via a distribution list that is of internal users) don't work when they seem fine for other members of the same list.

...

ah... just noticed that the membership of that list was out of synch for some reason. Odd that she had received the share invite, but no longer member of the list..

Anyway, I have resolved it by correcting the list members - my bad I guess.

Gren Elliot · Post by **Gren Elliot** » Tue Jul 14, 2015 8:44 am

It should result in more detail in the logging in mailbox.log. Guess that doesn't matter now as you have got to the bottom of the problem

Al-MacLean · Post by **Al-MacLean** » Thu Jul 16, 2015 4:24 am

Thanks Gren.

Further to the above, I thought initially it was my own mistake that I had missed Sarah off the distribution list, but I have since found that the DL had actually removed some members without my input/action.

Model:

Zimbra version 8.6, with patch 3 applied.

We currently have a total of 20 user accounts (excluding admin).

Of these, 13 are head-office user accounts, all of whom are members to a internal distribution list covering that group.

We have just 8 distribution lists, including the general HQ staff one above.

Most users are using the web client, though I have distributed the Zimbra Desktop via Group Policy to the user computers (mix of laptops and desktops - all Windows 7 Pro).

I am currently the sole admin-level user to Zimbra.

Issue:

I found my own account had been removed from two of our dist-lists, including the HQ one. I know I had not requested un-subscribe, nor changed things through admin.

One user (a member of the HQ Dist-List) locked his PC while away from his desk (common practice).

On return, he found his web session to Zimbra said it had timed out and had auto-logged him out. So the user tried to log in, but the system refused to let him in. He had previously ticked/checked the box on the log in form to "remember me".

When I checked the Locked Users search list in the admin console, his account was listed as Locked, so I simply set him back to Active.

However, we also then found that his shared folders were all being retracted.

On further checking, I saw that his account had been dropped from the HQ Dist-List members, as mine had previously (*although I had not experienced the locked account).

So the big question is, why would user accounts have been dropped/removed from a distribution list without my adminisrative action explicitely doing this?

Many thanks for any ideas on settings I could check - or have I discovered a bug?

Alec

Gren Elliot · Post by **Gren Elliot** » Thu Jul 16, 2015 6:00 am

It seems unlikely that distribution lists have randomly changed by themselves. May be worth going back through your logs and seeing if there is any activity that may be related. I'd suggest also looking to see if you can work out why the account got locked. Potential intrusion attempts combined with unexpected changes. Hmm, I know what I would be focusing my attention on...

Al-MacLean · Post by **Al-MacLean** » Thu Jul 16, 2015 6:34 am

So... you're suggesting our fresh install has been hacked?
Or that an internal user has somehow gained access? Very small team without the required skillset (or inclination) - I can be pretty darn sure it's not internal.
Could you point me in the direction of the log file to examine please? (I best be sure).
I would obviously hope this is not the case for an external penetration. We have a dedicated firewall in place that prevents external admin connections (the required ports are blocked). Only the mail transport ports (25 and the SSL/TLS equiv, plus IMAP only through SSL/TLS) and the user web ports (80/443) are allowed. (I can only admin remotely if I connect via VPN.)
I'm not suggesting there is definitely a bug in Zimbra, but the behaviour is pretty strange. I appreciate I'm a total new-boy to admin on this platform and recognise it could be something I have incorrect or misunderstood how it operates - but then why would it only effect a small number of people and not all of them? I'm pretty sure I set them up all using the same process steps (create all accounts, then added to the DL).
Thanks,
Alec

Gren Elliot · Post by **Gren Elliot** » Thu Jul 16, 2015 7:50 am

I can't say whether you've been hacked or not but it would certainly be something I would consider as a possibility. I suspect most systems get hack attempts within seconds of being connected to the internet, so freshness is not much guide to how safe they are.
Most of the zimbra logs are in /opt/zimbra/log/ mailbox.log being the main one. Logs for earlier days will probably have been compressed - e.g. mailbox.log.2015-07-15.gz. You could use zgrep to search for patterns in there - perhaps look for all mentions of the users involved and the distribution lists. audit.log may be interesting too.
Also worth looking at the system logs - probably in /var/log/ - e.g. /var/log/auth.log which might give you a feel for how many failed auth attempts you are getting via ssh.
I'll be honest and say that I'm not a sysadmin - you would be better getting advice from people who have to worry about protecting their systems as part of their day job.
The problems you mention are related to directory changes, so it may be worth considering switching on logging for LDAP. Add the following to /opt/zimbra/conf/log4j.properties.in
log4j.logger.zimbra.ldap=TRACE

and restart Zimbra
If the problem hits again, you should see evidence of when it happened by grepping for " ldap -" in mailbox.log. You will probably want to backout this change when you've got to the bottom of things to keep a lid on disk space used for logging