[swift-users] Smartcard login with Openfire 4.1.3 and Swift 3.0 client

[Kevin Smith]

Hi,

On 23 May 2017, at 14:03, Butch MacDougall <butch.macdougall at junotech.com> wrote:
> Please help. Windows 10 client and Windows Server 2016. I have been looking at this for quite a while. I was originally looking at CLO as well, but need to drop back to smartcard login. I am using Openfire 4.1.3 with the Swift 3.0 client (Swift XMPP Client ) Is it even possible to make this work with these two products?

I’m afraid that while we’ve obviously got experience with this setup against M-Link, we can’t offer support for Openfire configuration issues.

> Because I am using a smartcard, I have a number at com as my subject alternative name (principal name), which is used in Active Directory for CLO, but the user also has user.name at this.that.com in Active Directory as an available user logon name (pre-Windows 2000).

What is needed in the certificate for Openfire to authenticate it is down to Openfire configuration, sorry.

> When I put user.name at this.that.cominto user address the client debug console shows that starttls is required, then mechanism EXTERNAL is negotiated. Then I get a <not-authorized/> back from the server, the client GUI shows "login/password invalid”.

That sounds like a(n Openfire) bug at first glance - the server shouldn't be offering EXTERNAL unless the certificate can be authenticated.

> When I use number at com for my user address in the Swift client, which matches the the principal name on the smartcard cert,

The ‘user address’ should be whatever the XMPP server thinks your JID (XMPP Address) is for that account.

> I have to manually define the server, but still receive <not-authorized/> back from the server, the client GUI shows "login/password invalid". I have also tried number at chat.this.that.com(XMPP domain) and still receive same <not-authorized/> response. I also tried with the RFC822 name on the smartcard certificate. I have the same results with Swift 4.0 beta2 and Openfire 4.1.4. Looking at the all.log on the Openfire server, it looks like it is trying to look up the user as the subject CN property only of the certificate provided (lastname.firstname.number), which it can't find in active directory. I tried adding lastname.firstname.number at this.that.com into Active Directory for the user for the user logon name, but that did not change the outcome.

I’m afraid I think you’ll need to take this up with your Openfire support, from your descriptions this sounds like server configuration issues.

/K