Bug 1129811

I originally submitted this as a Fedora bug #862326

Colin,

Thanks a lot for a research and deep dive. However there is a a bit of clarity that I am missing here. So please bear with me a bit.

= Which use cases we want to support? =

There are several items here:
a) User - is user an AD user or IdM user?
b) Machine is machine expected to be in AD domain, IPA domain, IPA domain that trusts AD, all of the above or you do not care and leave up to us to tell the recommended approach?
c) Do you expect user to authenticate using user name and password or you also expect user to authenticate with a cert? Do you expect user to get a TGT as a result (I suspect yes based on the comments above)?
d) Do you expect that VPN is a 3rd party VPN like Cisco or you expect it to be an open source one that Red Hat delivers?
e) Do you expect the VPN and RADIUS server behind it to be a part of IdM domain or AD domain?

As you can see this creates quite a massive combination of potential use cases so it would be nice to understand which ones are the primary ones.

= Comments about the request =

SSSD uses Keytab. This is its "password". It is not rotated. We have an RFE but so far but it is not implemented yet. There was no pressing need so far. While it is a policy in AD domain we have discussed this aspect with MIT Kerberos gurus and they are confident that Keytabs can live for extended period of time without rotation without security risk so it is sort of precaution rather than a hard security requirement to rotate them.
    
SSSD can have a cert provisioned to it to identify the host if it is joined into IPA domain so this can be used to do the machine level authentication.

= Plans =

We have plans to allow better certificate management in IPA to provision certs for different purposes and differentiate certs we issue for hosts, VPN, mobile, puppet and so on. This is in work happening upstream.

One of the ideas that we are going to promote is ability to transition from Kerberos to Certs and back. It is already possible using certificates to have a Kerberos authentication (pkinit). One of the ideas we have is:
- Machine gets online and connects to the network using its cert
- User is prompted for an authentication (hopefully 2FA)
- SSSD talks to IdM using Kerberos over internet and sends 2FA credential to it.
Here are MIT projects that made it possible that IdM is implementing:
http://k5wiki.kerberos.org/wiki/Projects/HTTP_Transport
(FAST OTP implementation did not have a special page)
http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS
- IdM authenticates user over internet and gives him TGT
- IdM returns in the ticket or client (SSSD) connects to a service using service ticket to get a short lived cert that matches the TGT lifetime (or can be scoped to be shorter). As a result a cert is delivered to the client.
- SSSD uses the cert for VPN authentication rather than user name and password. 

This setup allows for AD and IdM users coming from a Linux system joining the IdM domain. This is the primary use case we thinks is worth addressing. However your answer to the questions below might augment this vision.

Thanks
Dmitri

And I forgot one more question: are we talking about a Linux machine or windows or something else?

We also have some interesting ideas about mobile devices, i.e how to get them on the network in a secure but manageable way. We have a POC for that.

Hopefully I can answer these...

= Which use cases we want to support? =

> There are several items here:
> a) User - is user an AD user or IdM user?

Okay the issue here is that this is a standard 802.1x mechanism for authenticating access to the network layer.

The deployment is usually AD <-> RADIUS <-> WiFi Controller <-> Client machine, so that will be what is in the field. But I'd guess there is no reason the backend of the RADIUS shouldn't be IdM (this is the new name for IPA server?). Allowing this dual authentication (or even just user authentication alone) to be via IPA. 

The basic deal is that all that has to happen is that for the user authentication piece to succeed is that the user needs to successfully authenticate using RADIUS (via the WiFi Controller). The backend authenticator is immaterial (IPA or AD or anything). 

> b) Machine is machine expected to be in AD domain, IPA domain, IPA domain    
> that trusts AD, all of the above or you do not care and leave up to us to 
> tell the recommended approach?

All of the above should work I'd guess with suitable trusts that RADIUS can see. Remember this interaction is purely happening in RADIUS to negotiate the network link layer (layer 2).

We only have AD here. But *THIS* RFE is purely a client issue, it doesn't need to know about the backend. As all interaction is layer 2 via a WiFi controller to the RADIUS (or some other authentication checker).

Like user authentication all that needs to happen for machine auth to succeed is that a username of "host/machinename.domain" with the machine's password as the password. Nothing comes back to the client in terms of a security token or anything. It just gains network connectivity.

c) Do you expect user to authenticate using user name and password or you also expect user to authenticate with a cert? Do you expect user to get a TGT as a result (I suspect yes based on the comments above)?

Nope, this is network connectivity, nothing else.

According to the CISCO document I linked it's possible to do machine authentication via certs (EAP-TLS) or via machine password (PEAPv0/EAP-MSCHAPv2). This isn't up to the client to choose though it's depends what was setup in the controller. 

We use PEAP (machine passwords) (strictly PEAPv0/EAP-MSCHAPv2)  . The reason we do (though wasn't up to me personally), and I think the reason the standard was written is that you don't need a PKI infrastructure (or certs for each client). You purely need server cert just to encrypt the interaction. Well so I remember reading somewhere....

The fact the machine password is used means you cannot perform a domain join on this network as you will not have a machine password to authenticate to the network link layer. 

You don't get a TGT out of this. The way a Windows client does this as maybe isn't clear from my original post. Once it passes machine authentication (at boot) to the WiFi (or 802.1x network) it gets dropped into a role (on the wireless controller) that allows access to the authentication and infrastructure services (DNS , DHCP etc) only. They then get an IP and can lookup auth servers etc. This then means when a user logs in they can get a TGT and look up stuff via LDAP etc etc. It's only then that a further network link layer negotiation happens (authentication via the users credentials (layer2)) to allow them access to the whole network. 

So the obtaining of TGT's and authentication is normal, as in no different from a non-802.1x network.

d) Do you expect that VPN is a 3rd party VPN like Cisco or you expect it to be an open source one that Red Hat delivers?

This is purely negotiating the network link, there is no VPN here.

e) Do you expect the VPN and RADIUS server behind it to be a part of IdM domain or AD domain?

Again no VPN. But basically as I said earlier. The RADIUS just needs to authenticate passwords whether person or machine ones. The client doesn't speak to radius it purely speaks to the WiFi controller. The controller speaks to radius (or some other auth system). This is invisible to the client.

To answer your latest question and basically summarize this. The point of this RFE is to replicate the Windows implementation of this standard (okay a standard worked out between MS and Cisco) but widely deployed....

RHEL has already all the necessary encryption and wireless authentication types necessary to implement this (the supplicant is fine). What is missing is a method of holding the machine's password somewhere that can be used automatically to pass the machine authentication and grabbing the users password (maybe via PAM) to pass the second stage, if using dual authentication. i.e the hard bit is already there.

Hopefully in WiFi expert in RH may know the details of this. It's not really a directory services issue but will probably need interaction with SSSD on the client side to make this clean.

The Wikipedia articles on these two may help:

http://en.wikipedia.org/wiki/IEEE_802.1X

http://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol

The good news is that there is a lot less to this than it looks, it's just the alphabet soup of this topic that makes it look complex....

What would help me in the short term (without a full solution) would be if someone could answer this question:

5/ Is there any way to fully script a connection in network manager? i.e one way to workaround this issue for us is to spawn a script that can perform machine auth piece. There are post connection scripts but can you do pre-connection scripts? So if you hit this network in NM, it would run the script, which would do machine auth, then the GUI piece could perform the user auth. 

Any thoughts on this?

We've hacked together a way to achieve this dual authentication.  It's pretty scrappy, but gets the job done.  Our method is documented here in case it's useful to anyone:  http://redirdevnull.blogspot.co.uk/

We use wpa_supplicant to perform the computer authentication when the system boots, and then NetworkManager takes over to do user authentication once the user has logged in.  Our machines are joined to AD using Dell's Quest software, so our scripts rely on Quest for things like grabbing the machine password.  I imagine this would be possible using sssd, but I haven't explored how.

move to RHEL8. At this point, it must be first fixed there.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.