0 Replies Latest reply on May 23, 2017 6:08 AM by Paul MacDougall

    Smartcard login with Openfire 4.1.3 and Swift 3.0 client

    Paul MacDougall

      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? Does anyone have any instructions they can provide? I can use CLO (cryptographic logon) with my smartcard to login to the workstation, so my certs at a domain level are working. Openfire is configured with LDAP and working for the user database. The Swift client works if I set SASL.mechs = PLAIN, only. If I were to enforce CLO, then the user would not know his password, so I would have to be able to logon with only the smartcard cert. I know that the Swift 3.0 client will work with smartcard based logon because I am able to login to a blackbox XMPP server with only my smartcard. On that connection to the blackbox XMPP server, I can see that starttls = required and mechanism = EXTERNAL. On my domain, I have SASL = EXTERNAL only and the following:
      ldap.startTlsEnabled: true
      sasl.mechs : EXTERNAL
      sasl.gssapi.useSubjectCredsOnly: false
      sasl.realm: MY.FQDN
      xmpp.client.tls.policy : required
      xmpp.client.cert.policy : needed
      xmpp.client.compression.policy : disabled
      xmpp.auth.anonymous : true
      xmpp.server.compression.policy : disabled
      xmpp.server.dialback.enabled : false
      xmpp.server.tls.enabled : true
      xmpp.socket.ssl.active : true

      DNS SRV records are in place.
      For my Swift client, I have singleSignOn = false, because I think this may be a bridge too far and using the smartcard cert for login will be a quicker solution. Because I am using a smartcard, I have a number@com as my subject alternative name (principal name), which is used in Active Directory for CLO, but the user also has user.name@this.that.com in Active Directory as an available user logon name (pre-Windows 2000). When I put user.name@this.that.com into 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". When I use number@com for my user address in the Swift client, which matches the the principal name on the smartcard cert, 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@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@this.that.com into Active Directory for the user for the user logon name, but that did not change the outcome.