A few days ago I encountered a strange problem in a customer’s testing environment. The environment consisted of two enterprise pools with 3 Front Ends in each pool running Skype for Business Cu3. Signing in from a mobile device had stopped working for some reason.
Inspecting the logs I could see that authentication worked as expected and the clients all received their webtickets properly but clients still wasn’t able to sign in. Looking at the client logs i found the following.
INFO APPLICATION CAlertReporter.cpp:64 Alert received! Category 2, Type 300, level 0, error E_UcwaUnavailable (E2-3-48), context ‘handleUcwaAppSessionRequestError’, hasAction=false
So obviously the client didn’t get the expected response from UCWA. Inspecting the Mobile Gateway (reverse proxy) logs we could indeed see that when our client tried to access /ucwa/v1/applications it received a HTTP 503 Service Unavailable response from the Front End. Accessing the URL directly on the Front End also gave us the 503 response. When accessing the URL directly on any of the other Front Ends in the pool we received a 401 Unauthorized response which is the expected response.
We issued a restart of the web server on the affected Front End from the IIS manager and tried again. Unfortunately this didn’t solve the problem, the clients still received the 503’s. I’ve seen issued before with a restart issued from the IIS manager. So we tried again using an iisreset issued from a command prompt and… Voilá, the client was able to sign in and direct access to the URL now gave a proper 401 response.
Conclusions: resets from issued from the IIS manager does not really restart and flush the web server. While I still don’t know exactly what caused the 503’s I believe it might be related to system resources, as this was a testing environment the machines had limited resources.
Hello all! I’m currently in Atlanta and attending Microsoft Ignite at the Georgia World Congress Center. I’ll mainly be going to sessions but also spend some time in the PointSharp booth (#2171).
If you’re also attendig, please come by and say hello!
You have probably heard about modern authentication, there’s a lot of talk about it. Especially when it comes to Office 365 and Azure. You might have seen the acronym ADAL which is the Active Directory Authentication Library which is modern authentication. So, what is modern authentication and what does it mean for Skype for Business?
Well, let’s first take a look at what modern authentication is before we start looking at how it works in Skype for Business. While modern authentication is something that is presented as something new and shiny, the corner stones and the foundation is nothing new. Modern authentication simply put, is federation. Which in the Microsoft world means AD FS.
So what does this mean for Skype for Business? Well, to be honest, not very much. It works pretty much the same as the old Passive authentication which was also based on federation. Sadly there’s no EWS integration unless you are using Office365. Hopefully this will change.
The sign in flow differs from the original behavior: An S4B client attempts to connect to the S4B server, gets redirected to AD FS where the client is presented with an authentication form, user authenticates and gets a claim and is then redirected back to the S4B server where the claim is accepted by the S4B server and the client gets the webticket. So what has changed?
From my initial tests I’ve found that they’ve changed the federation protocol to Oauth2 which comes as no surprise as it is being pushed quite heavily. Secondly, ADAL support is built into the client so unlike passive authentication the client doesn’t spawn the browser window the same way (to present the authentication form) so it looks a tad bit different.
The image below is a screenshot of the sign in using modern authentication and the PointSharp MFA to provide two-factor authentication.
If you want to test modern authentication you can follow the steps on TechNet. Just remember that you need an AD FS server as well as the scripts needed to enable Oauth2 for Skype for Business (http://aka.ms/sfbadalscripts)
The December update (version 6.2.0.24) of the Skype for Business iOS mobile app contains a bug that breaks exchange integration. It’s quite annoying as it keeps popping an error message inside the client over and over.
When the client receives the Exchange Autodiscover request and parses the response it attempts to connect to the internal URL of EWS instead of the external URL. Since the internal URL most often aren’t reachable from the external network it wont reach the Exchange server.
I can think of two workarounds to this problem
Set internalURL and externalURL to the same value. This might work for some companies depending on their DNS infrastructure but generally I think this is a bad idea.
Rewrite the response data between exchange and the client so that the internalURL value matches the externalURL value.
Today’s post will be a review of the Voyager Focus UC headset from Plantronics. It is a bluetooth on-ear headset that is focused on communication. The name “Focus UC” becomes evident whenever you use it.
I’ve been living with this headset for the last couple of weeks. I’ve used it in any situation that requires a headset, be it a Skype for Business meeting or watching the latest episode of a TV-series. My iPhone has been constantly connected to the headset. The same goes for my laptop whenever it has been powered on.
When using a headset there are a few basic requirements that needs to be covered before we can go into specific details.
Comfort
I’ve always been cautious when it comes to on-ear headsets because my ears are very sensitive. Some days I spend the majority of the day in Skype for Business meetings, which means hours on hours without taking the headset of. I have always thought that the constant pressure on the ears would make an on-ear headset impossible for me to use. Plantronics have proved me wrong, the Voyager Focus UC is very comfortable even after wearing them for a long time. This is because the ear pads are very soft and the pressure on the ears are very light but not as light as to cause the headset to slip out of place.
Audio quality
Needless to say audio quality is very important to a headset. The Voyager Focus UC does not disappoint in this department. The Active Noise Cancellation effect is, of course, less prominent than in an over-ear headset but for an office environment its just where it needs to be. I’m not bothered by any surrounding sound at all while I’m working at my desk. When listening to music the quality is good, I’m quite impressed by the bass delivered by the headset. While good audio quality is _quite_ common in headsets I find that mics are often lacking in quality. The mic of the Voyager Focus UC is nothing short of fantastic. I’ve tested it outside in windy conditions and it still performs really well.
Form factor
The Voyager Focus UC is a relatively small headset that is easy to carry around in, for instance, a lap top bag when you’re not wearing it. The build quality is good and feels robust while being very light weight.
From good to fantastic
The above categories are fundamentally important in a good headset. So what can make a communications headset like this go from good to fantastic? In the case of the Voyager Focus UC it’s the combination of doing a fantastic job in the categories above with all the extra features Plantronics has incorporated into the device. Features that I, from now on, almost consider mandatory in a headset.
Controls
Apart from the standard controls of volume and answering/hanging up a call I really appreciate to be able to play/pause and skip tracks when listening to music. Being able to mute the headset with a button is s must for me but it’s not necessary with this headset (more on this later).
Connectivity
The Voyager Focus UC is a Bluetooth Class 1 unit which gives it a fantastic range when paired to another Class 1 device. It’s possible to be paired with up to two devices simultaneously. Whether it’s a call to my mobile phone or my Skype for Business PC-client I just click the answer button. And to all the Skype for Business people out there; when answering a call on your mobile phone the Plantronics hub sets your presence to “in a call”. That’s really neat.
Smart Sensor
The headset comes equipped with a Smart Sensor technology. This sensor knows whether you have your headset on or off. It can be used to answer calls by putting your headset, mute the mic when you take your headset off while in a call and unmute when you put it on again. It also pauses your music if you take it off and resumes when you take it on. Another nice thing is that when you take it off it disables the active noise cancellation to conserve battery when you’re not using the headset.
Battery life
The talk time is around 10-12 hours and about 8 hours for music/video. Meaning that even after a full day of meetings and music in between I still have battery left.
Conclusion
I am extremely impressed with this headset. I might be preaching to the (Skype4B) choir here but this headset is truly fantastic. Plantronics has made a fantastic headset that should cover any communication needs. If you are treating yourself to a new headset this Christmas I not only recommend this headset, I urge you to get the Voyager Focus UC. You won’t be disappointed.
I was at Modern Workplace Summit in Olso a week ago and did a presentation together with Fabrizio Volpe (@fabriziovlp) about security in Skype for Business. A part of my presentation touched upon the certificate based authentication used by Lync and Skype for business. After a twitter conversation with Randy Chapman (@randychapman) and Alexander Holmeset (Holmez85) I decided to write a short post about it.
Skype4B uses an authentication method called TLS-DSK which is a certificate based authentication. No it’s not client certificate authentication, it’s certificate based authentication. There is a very big difference and from a security perspective it’s important to understand that it’s not client certificate authentication.
When a client has authenticated to the server (Kerberos or NTLM) it gets a webticket. That webticket is then used to contact the Certificate Provisioning Service and retrieve a “Skype4B/Lync certificate”. This certificate is then used for subsequent authentications using TLS-DSK.
By default this certificate is valid for 180 days. This means that the client can use this certificate to retrieve new webtickets for 180 days. When a webticket is retrieved using the certificate, no check towards Active Directory user object is done. This means a locked AD account can retrieve webtickets without any problems. It’s only when an NTLM authentication is done that the AD is involved in the authentication process.
So the obvious question here is of course; “is there any way to set how long these certificates should be valid”? Yes there is, it can be done in PowerShell. This setting is a part of the web services configuration. The command below sets the expiration time of issued certificates to 24 hours.
iOS 9 is here! And like most iPhone owners I downloaded iOS 9 yesterday and installed it. If you or your Lync users haven’t done this already you might be in for an unpleasant surprise.
After the install was done I launched Lync and and hit the sign in button. I was greeted with the following error mesage.
After doing all the normal troubleshooting I still couldn’t find the reason for the error.
Thanks to Guy Bachar’s post I first of all realized that I wasn’t alone in having this issue. Turns our that for some reason; if your regional setting on iPhone doesn’t match your iPhone language you can’t sign in to Lync if you are on iOS 9.
This worked fine in iOS 8 and to me it’s really frustrating. I prefer to have my regional settings set to Swedish to get date, currency and all that in the, for me, correct format but I still want my iPhone language set to English.
I also want to point out that for me it wasn’t enough to just set my iPhone language to “swedish”. I had to re-install the Lync app from AppStore to get it working again. I really hope this gets sorted soon.
Update: Microsoft has a KB for this https://support.microsoft.com/en-us/kb/3096704. I was a bit sad to see this: “This problem is fixed in the Microsoft Skype for Business for iOS app that will replace Lync for iPhone and Lync for iPad when it’s released. No fix for this issue is scheduled for the current releases of Lync for iPhone and Lync for iPad”.
Thanks to Marc Bertasius (@marcbertasius) for bringing this to my attention.
Hello! Those of you that read my twitter already know that I am going to Microsoft Ignite next week. Those who didn’t know would have known if they followed me on twitter (hint hint). Anyway, I’m going to Ignite with many of my PointSharp colleagues. I’ll be going to sessions, stalking various Skype MVPs and of course be in our booth (#563) and talk about Skype for Business security.
We will also be bringing our brand new version, PointSharp 4.4, to the conference which includes some nice features for Lync/Skype4B.
A new admin UI
Previously we used the IIS Manager to configure our reverse proxy, in this version we have built our own UI which makes administration and deployment much easier.
Device registration for PC
In our previous versions we created a partnership between a user and their mobile device. This ensures that credentials cannot be stolen and used on another device. Now, we are bringing this functionality to the Edge server which means that we can do the same for PCs.
Block clients
We have made it possible to block an active client. For instance if a user’s phone is stolen/lost we can block that specific device. The client becomes useless, it doesn’t even matter if the correct credentials are stored on the mobile device or PC. No more disabling the whole account.
These new features combined with application specific passwords (no need for domain passwords on devices), pre-authentication and even two-factor authentication provides a lot of extra security to Lync/Skype4B. I have to say I’m proud of what our team has has done. More info at PointSharp
Are you coming to Ignite? Come talk to me in our booth, ping me on twitter (@techmikal). I’ll also be at some of the UC oriented parties in the evenings. I hope to meet you there!
This post is going to be about what seems to be one of the least discussed features in Lync. I’m talking about the Lync Kerberos Account… No, don’t you dare close this window. We know it’s there, the Best Practice Analyzer tells us it’s considered ‘best practice’ to enable Kerberos authentication for Web traffic. Let’s keep that in mind while I try to unravel the reasons. To do so, and still make some sense, I have to start by explaining (quite) a bit about Kerberos and how it works. For any of you who are familiar with Exchange probably recognizes the Exchange Alternate Service Account (ASA), this is the Exchange equivalent of the Lync Kerberos Account. This is going to be a long post, and much won’t be specific to Lync, but I believe it’s worth reading and I believe people need to start deploying the Lync Kerberos Account.
Kerberos is complicated and most often you don’t have to care much about it, because it all happens automatically under the hood. While it’s great that it works automatically (most of the time) it shouldn’t be overlooked as it’s very important. It is the preferred authentication protocol for Windows. Most services that you access daily on your LAN are accessible to you because you have authenticated using Kerberos. Lync is no exception, it wants to use Kerberos as much as possible, if you’ll let it.
Today there are three commonly used authentication protocols in Windows. There’s basic authentication which, by itself, offers no security at all, that’s right, no security at all. Then we have NTLM, which was the preferred authentication protocol in pre-Kerberos times. It is still widely used today, because unlike Kerberos authentication, it doesn’t require that the authenticating client has access to a Domain Controller. This is the reason internal Lync clients try to authenticate using Kerberos and external clients fall back to NTLM. Finally, we have Kerberos.
If you aren’t interested in how it works and just want to deploy the Lync Kerberos account there is a TL;DR almost at the end of the post.
Great, you’re still reading. It gets a little complicated but I will do my best to explain it as simply as I can without omitting very important things.
Kerberos
Kerberos is an authentication protocol that is based on tickets that allows users and computers to authenticate in a secure manner over a non-secure network. The tickets that are used to authenticate never contains any passwords which means that a users password is never sent over the network. It uses symmetric key cryptography and requires a 3rd party that is trusted by the entity that is authenticating and the one that requires authentication. This 3rd party is the KDC (Key Distribution Center). In the Microsoft world this is the Domain Controllers. The KDC knows the secret key for all users and all computer accounts. All secret keys are a salted hash of the account password. The KDC is also trusted by all domain members, meaning that it can validate all tickets and any ticket issued by the KCD is trusted by all domain members. This is very important as we go on. As mentioned above Kerberos is based on tickets. There are different types of tickets and they are used for different things. To access a service you need a service ticket, a service ticket proves your identity to a computer that is running a service. To get a service ticket you need a Ticket Granting Ticket (TGT). To get a TGT you must authenticate yourself to the KDC.
In the following example a user wants to access an OWA (It’s a little easier to use as an example than Lync). The whole authentication process starts when the user logs on to the workstation.
The user signs in to the workstation, when they do, the workstation will contact the KDC and request a Ticket Granting Ticket (TGT). The requests consists of a plain text part which includes among other things, the username. A portion of the request is encrypted with the users password. This is called the Authentication Service Request (AS-REQ).
The KDC receives the request and inspects the plain text part where it can see who is this person claiming to be. It then looks up the user and in it’s database where it also finds the users secret key. It uses this secret key to decrypt the encrypted part of the message. If it’s able to decrypt the message it knows that the user is who they claim to be (or at least that the person is using the correct password). Now that the Domain Controller knows who the user is it will go ahead and respond with a TGT. This TGT contains information about the authenticated user and is encrypted with the KDC’s secret key which is not known to the workstation. It stores this TGT in the memory, for the sake of this example let’s call it the Kerberos memory, for as long as it is valid (10 hours by default). The response itself is called the Authentication Service Reply (AS-REP).
Now remember that step 1 and 2 happened when the user logged into their workstation. Now the sequence continues when the user decides to access the OWA. This happens, let’s say, an hour later.
The user tries to access the OWA anonymously. The server responds with a HTTP 401 status code, meaning it requires authentication. In the response there is a header named “WWW-Authenticate” with the value of “Negotiate” which tells the client which type of authentication protocol to use. In this case Kerberos. The workstation looks in its Kerberos memory, where it will notice that it doesn’t have a service ticket for the HTTP service of the machine hosting the OWA. It then contacts the KDC again with a service ticket request. The request states which service the client wants to access. This is specified by including the Service Principal Name (SPN i.e. HTTP/exchange-cas01.contoso.com). The client also attaches the TGT it received in step 2 (from the kerberos memory) to the request. This is called the Ticket Granting Service Request (TGS-REQ).
The KDC receives the TGS-REQ from the client. It reads the SPN in the request and searches it database for a user account, or computer account, with a matching SPN registered. Now that the KDC has verified that the SPN exists, it also knows which account that holds that particular SPN. To determine who the user is, it decrypts the TGT using its own secret key (the same it used to encrypt the ticket in step 2). If it successfully decrypts the ticket, it knows that it was issued by the KDC and therefore the content can be trusted. And the content contains… You’re right, it contains the users verified identity. Now the KDC knows which account that holds the SPN (the Exchange CAS) and the user who wants to access the service. It then responds to the TGS-REQ with a service ticket, which it encrypts with the secret key of the account that holds the SPN. The workstation then receives the service ticket. Note that since the service ticket is encrypted with a secret key unknown to the client, it cannot read the encrypted part of the ticket. The client stores this ticket in the Kerberos memory for as long as it’s valid. The response is called the Ticket Granting Service Reply (TGS-REP).
The workstation now connects to the OWA. It includes the service ticket, taken from the Kerberos memory, and uses it in the “authorization” header of the HTTP request.
The web server hosting OWA receives the request and inspects the authorization header. It extracts the service ticket and attempts to decrypt it using its own secret key. If it can, it means the KDC has encrypted it and it’s content can be trusted. From the ticket it is able to extract the users identity and their group memberships. The request is then authenticated and the user is served the requested contents.
I’ve made a small video that illustrates how the above example works
Important things to remember from the above example.
The server running the service (OWA) never contacted the DC. This means less load for the service and each client doing most of the job.
No password was sent over the network.
When a client has a valid ticket for a service it can be used as long as its valid, meaning no need to go through the authentication process again and again. Each request is authenticated but the client uses the same ticket.
The ticket sent to the service also includes group memberships which means authorization decisions can be made directly without contacting a Domain Controller.
NTLM
Now that we understand how Kerberos works (we do, don’t we?)… Well, at least we know the basics of how it works, which is enough for the scope of this post. Before we can get back to Lync we need to understand one more authentication protocol… I promise, its the last one for this post. We need to look into NTLM which is also used by Lync. Without understanding both protocols we can’t understand the pros and cons.
Unlike Kerberos, NTLM is not built on tickets. NTLM happens in three phases. These phases includes three different types, Type 1-3. So let use the same example as above. A client wants to access an OWA that is protected by NTLM authentication.
The client starts his browser and navigates to the OWA address.
The server responds that it requires NTLM authentication.
The client sends an NTLM Type 1 message that includes its NTLM capabilities.
The server responds with an NTLM Type 2 message that contains a generated challenge.
The client extracts the message from the server and uses it’s password to generate a Type 3 message that is sent to the server.
The server receives the Type 3 message, sends the Type 2 and Type 3 message to the DC.
The DC receives the Type 2 and Type 3 message. Validates the messages towards its database and responds back to the server with whether the user has successfully authenticated or not.
The server receives the responds from the DC and if it’s correctly authenticated it lets the client access the requested resource.
Seems a lot easier than Kerberos, right? Well, it has to do this for each request… Yes, each image, each JavaScript and each file… That’s not very efficient. There is NTLM authentication persistence that is meant to help with the above problem but it would work best with one CAS or only one Front End.
So after reading through the above we can quite safely say that we want to use Kerberos over NTLM where possible.
Load balancing
We’re getting closer now to the point of this post, the Lync Kerberos Account, and one of the reasons it’s considered best practice.
While a client dependant load balancing/fail over perhaps isn’t the most elegant solution, it makes it a lot easier to deploy. This works well for SIP traffic where the authentication is connection based. Meaning that when the connection is established and the user is authenticated the connection is kept open and marked as an authenticated connection. This way the client does not have to provide credentials with each request. There is one protocol which is not covered by DNS load balancing and still needs to be load balanced using a hardware load balancer, namely HTTP which is used for Lync Web Services. Lync Web Services is used quite a lot by the clients, which then risks falling into the NTLM trap mentioned above. Meaning each request has to be authenticated towards the DC. While this certainly works it’s not optimal at all. Why put more load on DC’s and network than necessary? Why use an inferior authentication protocol? There really is NO good reason.
How come it’s not deployed everywhere then? Because it works without deploying it and likely because Kerberos authentication is less well known and a little trickier to load balance. Hopefully it won’t be after reading this post.
While explaining Kerberos above I mentioned that it relies on SPNs to function properly. This is because tickets are encrypted with the key for the service that is known to the server hosting the service and the DC. In the following scenario we have lyncpool1.contoso.com that consists of three Front Ends (fe01-03.contoso.com). The overridden name lyncpool1-web.contoso.com DNS record points to the load balancer that is in front of all three Front Ends.
The client will connect to https://lyncpool1-web.contoso.com and from that name it will determine that it needs a service ticket for the HTTP/lyncpool1-web.contoso.com to which the DC will likely reply “no such service principal” because no such SPN exists. On some installations I’ve seen that the SPN does exist in one of the following configurations.
Registered to each Front End Servers computer account. This breaks Kerberos. Each SPN must be unique.
Registered to one Front End. This doesn’t break Kerberos but can’t be load balanced. When a client goes to the load balancer with a valid kerberos ticket and gets directed to a Front End that doesn’t have that SPN registered, it will fail. As you can see in the image below the client’s Kerberos ticket is issued to HTTP/lyncpool1-web.contoso.com. The request ends up at FE01 which does not hold that SPN.
So, what to do? Enter the Lync Kerberos Account!
The Lync Kerberos Account
The Lync Kerberos Account is a really smart idea that makes load balancing Kerberos for Lync Web Services a non-issue. Essentially it’s a computer account. When created it’s just that. Now comes the special part; when you assign it to a site the correct SPNs are registered to that account and all Front Ends in the site become aware of the account and can use it for authentication purposes. This means that each server in the pool knows the secret for that account that then can be used to decrypt Kerberos tickets. This also means that whether the client ends up at FE01, 02 or 03 it doesn’t matter because the ticket it sends is encrypted with the service key for HTTP/lyncpool1-web.contoso.com which all of them can decrypt and read because they have the secret key of the Lync Kerberos Account.
TL;DR Kerberos is an authentication protocol based on tickets. It’s better than NTLM. Always deploy the Lync Kerberos Account.
Now that we’re all on the same page (hopefully), how do we deploy this account? It’s quite simple.
First we need to create the account itself. New-CsKerberosAccount -UserAccount "Contoso\KerbAuth" -ContainerDN "CN=Users,DC=contoso,DC=com"
Then we need to assign it to our site. New-CsKerberosAccountAssignment -UserAccount "Contoso\KerbAuth" -Identity "site:Contoso"
Enable the topology Enable-CsTopology
Set the password for the account. Do NOT skip this step. Set-CsKerberosAccountPassword -UserAccount "contoso\KerbAuth"
And that’s it! The account is deployed. You can verify that the correct SPN’s has been added to the account by running. setspn -L KerbAuth
Verify that you can see the overridden internal Web Services SPN in the list (HTTP/lyncpool1-web.contoso.com). Also make sure that the DNS A record for lyncpool1-web.contoso.com is pointing to VIP on your load balancer for internal Lync Web Services.
If you receive client pop ups after you have enabled the Lync Kerberos Account it means you have missed something in the configuration.
You can verify your Lync Kerberos Account configuration by running the following command from the Lync Server Management Shell. Test-CsKerberosAccountAssignment -Identity "site:Contoso" -Report "c:\temp\KerberosReport.htm" -Verbose
I know this has been a long post, hopefully you found it interesting. Thank you for reading.
You’ve probably heard all about the new Outlook for iOS and Android that was recently released to the public. The app is a rebrand of Microsoft’s earlier acquisition of Accompli.
People have been writing a lot about this app but I just can’t refrain from making a post about this due to one of the obvious and one not so obvious problem with this app. Coming from the security side if things I just have to. Even more so since I’m working for a company that is creates security products targeting mobile e-mail.
No S/MIME support
For those of you unfamiliar with the S/MIME term it’s the Microsoft Exchange way of sending and reading encrypted e-mails. As long as the app does not support this, it’s simply not enterprise grade. While I like some of the aspects of the app, this alone makes it a no go for me. While I understand that many do not use encrypted e-mails on a standard basis it’s still half a client without the support.
Credential storing middleware
When I heard about this I thought it was a joke. I actually believed that someone wanted to be all anti-Microsoft and was straight out lying. Turns out it was true. When you configure your corporate, not your personal, e-mail account the app sends your corporate credentials not only to your Exchange server but also to AWS (will be Azure later this year) where it is stored. As if this wasn’t enough, a service from AWS then impersonates you and your device and connects to your company’s Exchange server. There it reads your e-mails and stores them. Office365 users should also take note that it doesn’t matter where your tenant is located since the AWS service is in the USA, so if you chose a location in Europe, perhaps out of security concerns this is bad news for you.
There simply is no excuse for this. There is no argument that holds from a security perspective. Storing your corporate domain credentials on their servers is wrong. Some will say the credentials won’t be used maliciously; What would you call it if I read your e-mail? What if someone hacks that service? Does your company allow you to give someone else the credentials you use to access corporate data?
Uninstalled and now blocked in PointSharp Mobile Gateway for Exchange.
On the 47th (http://www.theucarchitects.com/1489) episode of #TheUCArchitects podcast Steve Goodman (@stevegoodman https://twitter.com/stevegoodman) is right on the spot when he says that the app was released by a startup (Accompli) it was great. Looking at the app now that it’s released by a huge enterprise demands higher standards (to be fair, Steve said it needs more polish). Furthermore Steve talks about some of the security issues I’ve mentioned here, he also talks about a lot of the apps shortcomings (GAL support, Contacts, etc.). Thanks for reading, now go listen to the podcast.
Techmikal 