Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Mac Integration vs. password policies and multiple users (The Mac Integration doesn't play nice with multiple users and password policies)
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
Forgive me if this is covered in another posting. I didn't have any luck finding it, or a detailed description of its operation in the manual.

Here's the scenario:

• Multiple Macs (10.5.8) are bound to a Leopard Server's Open Directory/Kerberos database.

• Kerio Mail Server 6.7.2 running on 10.5.8 server. Domain is linked to OD Password server for users and authentication (Kerberos currently unused but imminent).

• Each Mac can have multiple users which are set up as mobile accounts that are part of the domain.

• When the Mac Integration for auto-iCal configuration is installed, it creates a directory server entry in Directory Utility that points to the Kerio server.

• The directory server entry is set to authenticate using the user name and password of the user account that was active when the package installer is run.

Here's the problem I'm experiencing:

† When multiple users are set up on the system, the LAST user for which the Integration installer is run, is the user whose credentials are stored in the directory entry FOR EVERYONE that uses that system. (not multi-user happy)

† When a user changes their password in Open Directory, the password saved in directory utility remains the same. Any LDAP calls made to Kerio now generate a password error and can ultimately lock out the user. (inhibits users from changing passwords according to our policies and punishes them if they do).

† We can't publish instructions on how to change the password in Directory Utility because it requires admin access and isn't necessarily tied to the logged in user.
---

Questions:

Is anyone else experiencing this?
Is this the intended behavior, or did I configure it incorrectly?
Is changing all the directory entries to a non-specific admin user a suitable alternative, or will that break something else?
Can I just disable authentication?
Should I abandon the auto-configure integration and just manually set up each user within each related application?

Thanks for any feedback or assistance.

Regards,
Lyle Millander
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
If anyone is curious, I called into support and learned the following:

It should be ok to either turn off directory authentication, or setup a generic "directory lookup" account.

The directory linking is just for public information and is not tied to the specific user.

I'll be testing this shortly (not from lack of trust, it's simply my job).
--

Hopefully, we'll see a new "auto-configure iCal" application that doesn't put user credentials into the directory link.

Cheers,
Lyle
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
niditahere wrote on Tue, 22 December 2009 02:54
well please do it as soon as possible coz i want quick results.....

I have no idea how to reply to you, I'm dumbfounded.
  •  
renefn

Messages: 158
Karma: 0
Send a private message to this user
This issue is also why I have put off migrating our users from Entourage to Apple Mail, Address Book and iCal. Our users are also just standard users with no priviliges to change settings in Directoty Utility.

Another issue is that since KMS doesn't support Kerberos or other forms of SSO between KMS and the clients, then the users have to change their passwords in Apple Mail, Kerio Sync Connector and iCal every time it changes, and that's a bit of a pain. In Entourage it's just a one-time operation but it would also be nice to have Kerberos support there. I have tried to enable NTLM in Apple Mail and that seems to work though since we're authenticated against our Active Directory.

The last issue is compatibility between Apple Mail and Outlook. These two clients simply can't sent mails with attachments to each other without completely messing up the structure of the messages... This is catastrophic and a complete showstopper for us...

Oups... sorry for hijacking the thread!

Regards,
Rene Frej Nielsen
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
renefn wrote on Wed, 23 December 2009 03:48
Oups... sorry for hijacking the thread!

Yeah! Shame on you! Wink

Quote:
Our users are also just standard users with no priviliges to change settings in Directoty Utility.

Admin or not, asking users to change the pw in DU would be painful; another place to change it, another level of complexity (support), and the whole multi-user issue.

A full Kerberos implementation could potentially make our lives much easier. It also has the potential to make support a more expensive proposition for us customers and for Kerio. Would you pay extra for a Kerio Connect Kerberos Edition (KCKE) that unlocks that feature? Or, would you prefer optional advanced support contracts and/or pay-as-you go Kerberos support? I think a combination of the two - A special download of the KCKE that doesn't cost extra, but warns away the uninitiated, coupled with both support options.

Now, back to the topic...

While testing, I hit a roadblock. I noticed that all my client machines were failing to authenticate/connect via the Kerio Mail Server DU entry (red dots). I'm fairly certain they were all green prior to my making our server a domain member vs. the replica it was before this weekend.

Kerio support suggested that my using non-standard ports could be an issue. I use port 3269 (msft-gc-ssl) for Secure LDAP as it is the default in Entourage for Exchange type connections, and because I didn't want to conflict with the LDAP ports that were once active on the server when it was an OD replica.

The iCal Auto-Configure installer automatically sets the DU entry to use SSL and 3269 (regardless of the initial web connection type, http or https). Kerio support, had me add ports 389 and 636 while he tested the DU setup, he could connect. The expectation was that it would setup DU with port 636, the standard port, and that would work. However, DU continued using 3269 and somehow still worked.

What changed to make 3269 now work? The added ports?!? To shorten the story, when I removed 389 from LDAP, my 3269 connection dropped. Add 389 back, green light again. So, somehow, this unused LDAP port has to be open for Secure LDAP on 3269 to work! Is it possible that even having 389 open as part of the OD replica also allowed 3269 to work in Kerio?

Ok, roadblock removed. Next comes the testing with auth disabled and with a static account substituted for the users' credentials. I should have time for that today or tomorrow. Gotta' hurry - coz' someone wants quick results! Razz

Cheers,
Lyle

[Updated on: Wed, 23 December 2009 14:41]

  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
Interestingly, even when 389 is closed, Entourage does connect to Kerio on 3269 without issue. Does this mean that the problem is in Directory Utility? Guess I'll have to do a packet capture too.
  •  
renefn

Messages: 158
Karma: 0
Send a private message to this user
I'm by no means a Kerberos expert but couldn't Kerio make KMS work the way that Apple's mailserver works by using the existing Kerberos ticket? On the Windows side we use SPA that takes advantage of NTLM so that's a SSO solution, and as far as I remember it also worked for Apple Mail, but that option isn't available in Address Book and iCal. Kerio Sync Connector is the same, but hopefully that can be replaced by CardDAV in Kerio Connect.

I know that if Kerberos isn't working properly then it's a pain and you might just as well start over, but unless you make an error someway then Kerberos "just works" in Mac OS X with either Active Directory or Open Directory at the other end. So it would be a great new feature!

I also did test with using the KMS account in DU, but if it worked then it was for a very short period. I have always had trouble with configuring DU against KMS when doing it manually, even though I really tried to do exactly what the iCal Auto config does. When using that it just works, but having the users credentials there is a no go.

I'm looking forward to hear your results. Our KMS is running a Windows Server 2003 Enterprise joined to a Windows Server 2008 Active Directory and it just works with no fiddling with ports, so I can't help you there. It's weird that it doesn't work now that it's just a domain member!

Regards,
Rene Frej Nielsen
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
After looking at my pcap, I can confirm that every time I refresh the directory utility listing (click on services, then back on directory servers), DU hits port 389 first. It then moves to port 3269. I can't think of any instance where this would be a desired behavior. Can anyone reproduce this in DU (regardless of KMS being in the mix)? I'll submit a bug report to Apple if someone else can provide some corroboration. I'm not currently worried about 389 being open as it's restricted to our LAN.

Rene, I imagine that Kerberos integration at that level is well within Kerio's abilities. So, could they? Probably. However, as you likely already know, the technical ability to add a feature is only one part of a deployment.

Back again to topic...

When I disabled authentication in DU, I still had a green light and the LDAP server log in Kerio showed the connection. However, auto-complete did not work in iCal (other than the contents of my Address Book application).

Entering a static admin account/pw in place of the user in DU worked, and allowed auto-complete in iCal to work.

So...

• I created a highly restricted Kerio local account with a name like "icalautocomplete."
• Logged into secure webmail as icalautocomplete
• Selected "Integration with Mac" and downloaded "Auto-configure iCal." The login for the icalautocomplete user is embedded in the installer.
• Run the installer and enter the pw for the icalautocomplete user when prompted.
• Launch iCal and delete the icalautocomplete user account and create the actual user account manually.

I can use the same pkg for all the installs to ensure that the DU entry isn't overwritten with a user account. An obvious alternative would be to simply update the user name and password in DU after every install.

Cheers,
Lyle
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
I think it's time to explain few facts:

- The green/red/yellow dot in DU setting has no real relation to iCal autocomplete functionality. It's just an indication of available LDAP (ie. it shows if TCP port 389 is available on the server).
- iCal autocomplete for CalDAV accounts is currently using LDAP lookups (Contact Search Policy in DU).
- User login is required in order to list users (make LDAP lookups for autocomplete). This restriction has been requested as it protects GAL and list of users. Otherwise spammers or attackers would have an easy way how to steal valid email addresses of local users.

Kerberos SSO is tricky. We are continuously trying to develop a solution which will be secure, simple and easy to setup. However, it is not easy task as KMS does not contain own directory server, DNS and Kerberos server. But believe me, working SSO is our goal as it will make our life much easier.

[Updated on: Wed, 23 December 2009 20:14]

  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
lylehm wrote on Wed, 23 December 2009 02:47
niditahere wrote on Tue, 22 December 2009 02:54
well please do it as soon as possible coz i want quick results.....

I have no idea how to reply to you, I'm dumbfounded.


Reply is pointless Smile) . It is a spam comment. Spammer's links are in the post signature (footer).
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
Kerio_pdobry wrote on Wed, 23 December 2009 13:49
it shows if TCP port 389 is available on the server).


It seems odd that Apple would check port 389 when the DU entry is set to SSL and port 3269. DU is primarily designed for LDAP servers which are almost always 389, but still...

Thanks Pavel. I always enjoy starting a thread that gets your attention. Would you agree that using a generic account for the DU lookup is a workable solution that avoids conflicts with password policies? Do you have any suggestions that may be easier/faster?

Regards,
Lyle

Damn Spammers. I noticed the links after my reply. Duh.
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
Using a generic account in DU authentication is a good solution. CalDAV standard and clients are evolving and LDAP will not be required for email address auto-completion. I believe we will stop using LDAP for that in some next Kerio Connect version.
  •  
Lyle M

Messages: 410

Karma: 7
Send a private message to this user
Thanks again Pavel. I'm looking forward to seeing how Kerio Connect evolves.

For chuckles, I shut off port 389 to see what happens:

1. As expected, get a red light in DU.
2. Packet capture shows no port 389 traffic.
3. Packet capture shows plenty of 3269 traffic.
4. Auto-complete does indeed still work - I went so far as to create a new resource on KMS and it was immediately available in iCal.

Funny I got hung up on that little red light. My auto-complete was "busted" which confused the matter for me in earlier testing. See the following related Kerio KB article:
http://support.kerio.com/index.php?_m=knowledgebase&_a=v iewarticle&kbarticleid=556 (Thanks Herrick)

Happy holidays all,
Lyle
  •  
renefn

Messages: 158
Karma: 0
Send a private message to this user
This thread has been very interesting... I look forward to seeing a more simple impementation without LDAP lookup for free/busy and perhaps Kerberos sometime in the future Very Happy

Regards,
Rene Frej Nielsen
Previous Topic: Disabling mail reception from outside for specific groups
Next Topic: migration message: Could not connect to KMS -solved
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Sat Sep 23 09:23:31 CEST 2017

Total time taken to generate the page: 0.00570 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.