road-warrior laptop vs password change in FreeIPA

[Harald Dunkel]

Hi folks,

I've got a few colleagues running Debian 10 or 11 on a laptop. Their account
is managed by FreeIPA in the office. On first-time login their laptop is
wired to the office lan.

When they are in home office they have a VPN connection (IPsec, wireguard
or openvpn) to the office, but since both wlan and VPN are usually activated
by Network Manager *after* login time I wonder what needs to be done to
update the login information cached by sssd, esp if the user has changed his
login password in the FreeIPA web interface?

By now I tried

	kinit username
	sss_cache -E
	service restart sssd

This did not help. kinit accepts the new password, of course, but it doesn't
update the cache, nor do the others.

Important point is that the user doesn't lose his cached entry, anyway.
Coming to the office just to register his new password is not an optiom.


Every helpful hint is highly appreciated

Harri

[Sam Morris]

On 16/07/2022 11:09, Harald Dunkel via FreeIPA-users wrote:
>  I've got a few colleagues running Debian 10 or 11 on a laptop.
> Their 
>  account
>  is managed by FreeIPA in the office. On first-time login their laptop is
>  wired to the office lan.
>  
>  When they are in home office they have a VPN connection (IPsec, wireguard
>  or openvpn) to the office, but since both wlan and VPN are usually 
>  activated
>  by Network Manager *after* login time I wonder what needs to be done to
>  update the login information cached by sssd, esp if the user has changed 
>  his
>  login password in the FreeIPA web interface?
>  
>  By now I tried
>  
>       kinit username
>       sss_cache -E
>       service restart sssd
>  
>  This did not help. kinit accepts the new password, of course, but it 
>  doesn't
>  update the cache, nor do the others. 
kinit is a standalone program that doesn't do anything with the password 
other than use it to get a TGT from the KDC, so running it won't updated 
sssd's cached password.

You need to perform a login via PAM (e.g., have the user lock & unlock 
their session, or run 'sudo -k && sudo -l'); sssd will cache the
user's 
password after it gets a TGT on behalf of the user.

The user experience for this is not ideal (it's something my 
orgnaization suffers from as well). My two ideas for how to improve it are:

  * A VPN that connects on boot, using the host's identity instead
    of the user (ideally combined with some clever Enterprise networking
    solution that puts the client into a separate network where it can
    do very little other than reach your KDCs until the user has
    authenticated)
  * Make the KDC service accessible to the Internet via ms-kkdcp, which
    is supported by FreeIPA, but I think you have to make some changes
    to kdc.conf on the clients as well

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

[Ian Willis]

On Sat, 2022-07-16 at 15:03 +0100, Sam Morris via FreeIPA-users wrote:
>  On 16/07/2022 11:09, Harald Dunkel via FreeIPA-users wrote:
>  > I've got a few colleagues running Debian 10 or 11 on a laptop.
>  > Their accountis managed by FreeIPA in the office. On first-time
>  > login their laptop iswired to the office lan.
>  > When they are in home office they have a VPN connection (IPsec,
>  > wireguardor openvpn) to the office, but since both wlan and VPN are
>  > usually activatedby Network Manager *after* login time I wonder
>  > what needs to be done toupdate the login information cached by
>  > sssd, esp if the user has changed hislogin password in the FreeIPA
>  > web interface?
>  > By now I tried
>  >      kinit username     sss_cache -E     service restart sssd
>  > This did not help. kinit accepts the new password, of course, but
>  > it doesn'tupdate the cache, nor do the others.
>  
>  kinit is a standalone program that doesn't do anything with the
>  password other than use it to get a TGT from the KDC, so running it
>  won't updated sssd's cached password.
>  You need to perform a login via PAM (e.g., have the user lock &
>  unlock their session, or run 'sudo -k && sudo -l'); sssd will cache
>  the user's password after it gets a TGT on behalf of the user.
>  The user experience for this is not ideal (it's something my
>  orgnaization suffers from as well). My two ideas for how to improve
>  it are:
>    * A VPN that connects on boot, using the host's identity
>  instead    of the user (ideally combined with some clever Enterprise
>  networking    solution that puts the client into a separate network
>  where it can    do very little other than reach your KDCs until the
>  user has    authenticated)  * Make the KDC service accessible to the
>  Internet via ms-kkdcp, which    is supported by FreeIPA, but I think
>  you have to make some changes    to kdc.conf on the clients as well
>  -- Sam Morris <https://robots.org.uk/>PGP: rsa4096/CAAA AA1A CA69
>  A83A 892B  1855 D20B 4202 5CDA
>  27B9_______________________________________________FreeIPA-users
>  mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to 
>  freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure 
Hi All,

We do the following however we don't distinguish "local" networks as
most people work remotely
All users connect via IPSEC using libreswan which starts on boot using
RSA keys
We join the workstation to the realm once the link is up. 
All traffic is sent via the IPSEC link. KDCs are only available via
ipsec.
DNS servers are hardcoded freeipa ones and reachable via the internet
and ipsec (otherwise there are issues with DHCP overwriting
resolv.conf) 
NFS shares are mediated by freeipa and automounted. (We tried NFS homes
but firefox and chrome hit the local drive too much and it was too much
work to change)
Drives are encrypted with LUKS

[Harald Dunkel]

As written before, wifi and VPN connections are established *after* the
user logged in using information stored in the cache. I can't help it.
Esp. I cannot support a VPN connection at boot time in a wifi network I
have no information about.

I understand that caching the user information is necessary. My question
is, how to update this cache after the user logged in using the cached
credentials?

There are a lot of security features in FreeIPA: password policies, one-
time-passwords, expiration dates, security tokens, etc. What am I
supposed to tell my colleagues? Whatever you do, never change your pass-
word to avoid confusion?


Regards

Harri

[Ian Willis]

On Sun, 2022-07-17 at 11:43 +0200, Harald Dunkel via FreeIPA-users
wrote:
>  As written before, wifi and VPN connections are established *after*
>  theuser logged in using information stored in the cache. I can't help
>  it.Esp. I cannot support a VPN connection at boot time in a wifi
>  network Ihave no information about.
>  I understand that caching the user information is necessary. My
>  questionis, how to update this cache after the user logged in using
>  the cachedcredentials?
>  There are a lot of security features in FreeIPA: password policies,
>  one-time-passwords, expiration dates, security tokens, etc. What am
>  Isupposed to tell my colleagues? Whatever you do, never change your
>  pass-word to avoid confusion?
>  
>  Regards
>  Harri_______________________________________________FreeIPA-users
>  mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to 
>  freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure 
So you're saying that your users are:
1 Authenticating to the device using a cached credential (they've
already booted/authenticated on the lan)
2 Authenticating to the wifi network using a cached or provided
credential
3 Authenticating to the VPN using this same cached credential.

If the password has expired everything breaks unless the protocols
support password changes in an integrated manner seamlessly. I'm not
sure how you'd do this.

The only reason why a cached freeipa credential is required is to
provide the system with a wifi password for the home office. (Otherwise
you could switch this off an have a more secure system.)
What I was alluding to was a simplified, layered approach with clear
with a clean separation of the security layers.

System boots, brings up network, brings up IPsec using RSA, user
authenticates with freeipa using kerberos  (if password changes is
required it happens here). OR alternatively
System boots, user authenticates using cached password, network comes
up after providing password, IPsec comes up and then interaction with
freeipa occurs.

Using a simple password to mediate both VPN and user access can open
your organisation up to Internet based attacks as you can't disable
credentials due to authentication failures and a successful
authentication gives you the keys to the kingdom. This isn't a great
security practice.

From a system point of view: 
the PC has a degree of trust as it holds the network access credential.
(TPM or a smartcard could help here)
The user has degree of trust
IPSEC is a trusted service
Kerberos freeipa is a trusted service.
Disabling split tunnelling simplifies the final picture.,

[Harald Dunkel]

On 2022-07-16 16:03:15, Sam Morris via FreeIPA-users wrote:
>  
>  The user experience for this is not ideal (it's something my
>  orgnaization suffers from as well). My two ideas for how to improve it are:
>  
>     * A VPN that connects on boot, using the host's identity instead
>       of the user (ideally combined with some clever Enterprise networking
>       solution that puts the client into a separate network where it can
>       do very little other than reach your KDCs until the user has
>       authenticated)
>     * Make the KDC service accessible to the Internet via ms-kkdcp, which
>       is supported by FreeIPA, but I think you have to make some changes
>       to kdc.conf on the clients as well
>   
I found a workaround using xscreensaver:

* establish the VPN connection to the office network, including the
   FreeIPA server
* use xscreensaver-demo to lock the screen now
* unlock the screensaver using the new password. This seems to
   update the local cached entry as well.
* use seahorse to change the passphrase of your login keyring
   accordingly


Worked for me.

Regards
Harri