Open gooseleggs opened 4 days ago
Thanks @gooseleggs, for the steps to reproduce. I'll try to reproduce this tomorrow.
can you expand on exactly what this means:
Create an identity with MFA required, or add MFA requirement policy to an identity.
I tried this but cannot reproduce. Here's a small gif demonstration:
Here are the exact ziti CLI commands I ran from powershell. I used ziti edge quickstart
to make a ziti instance that is fresh and clean and then ran invoke-webrequest (iwr) to pull down the version json from the controller. I ran the commands quickly to keep the gif size as small as i could:
# in the top window
ziti edge quickstart
# ---- divider ----
ziti edge login -u admin -p admin -y
$interceptJson = @{ protocols = @("tcp"); addresses = @("ziti.controller"); portRanges = @( @{low = 1280; high = 1280; } ) } | ConvertTo-Json
ziti edge create config mfatest-intercept.v1 intercept.v1 $interceptJson
$hostJson = @{protocol = "tcp"; address = "localhost"; port = 1280; } | ConvertTo-Json
ziti edge create config mfatest-host.v1 host.v1 $hostJson
ziti edge create service mfatest --configs "mfatest-intercept.v1,mfatest-host.v1" --role-attributes "mfa-needed-services"
ziti edge create service-policy mfatest.bind Bind --service-roles "@mfatest" --identity-roles "@quickstart-router"
ziti edge create service-policy mfatest.dial Dial --posture-check-roles '#mfa-needed' --identity-roles "#mfa-needed-users" --service-roles "#mfa-needed-services"
ziti edge create posture-check mfa mfa-required --role-attributes "mfa-needed"
ziti edge create identity mfatest --role-attributes "mfa-needed-users" -o c:\temp\mfatest.jwt
# if powershell 5:
$PSVersionTable
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
(iwr https://ziti.controller:1280).RawContent
# if powershell 6+
(iwr https://ziti.controller:1280 -SkipCertificateCheck).RawContent
Thanks @dovholuknf Here is a GIF for showing the issue. Hopefully I have captured all the settings that you need. I did think that it could be related to the version of the controller. It is VERY old (v0.28.1). However, a person with mac client had a flawless experience, so I think that rules out the controller?
Note that I did not apply any services to the identity. This does not change the fault, ie even if I associate a service I still get the issue. This has happened on two windows clients.
Thanks. I'll see if I can try to use the zac and an old controller. Is the zac equally as old? Would you be willing to send me one or a few identities which I could test with? Could you capture a feedback zip file and somehow get it to me so I could look at the logs? (Ideally with trace mode enabled)
i ran the ziti-edge-tunnel that comes with ZDEW 2.1.16 and it for me, it has the same behavior as the latest ZDEW does. You were able to get the 2.1.16 version of ZDEW to behave correctly, per your initial post but I could not. Could you perhaps have created the identity with the default or NON-mfa-required auth policy, enrolled it, then updated the identity to use that mfa-enforced policy?
It looks to me that the issue here is that the auth policy as you show ends up getting TOTP as required for secondary auth. That means it's a bit of a chicken/egg issue going on. I personally do think this is a flow we should support though, but I don't know if it's ever actually been used. I see most people using posture checks for TOTP, not as part of the authentication policy, but it makes to me that this flow should be supported.
Can you review my gif and steps and make sure I'm doing it how you're doing it? In it I do the following:
BTW that's the relatively trivial workaround to this too. Make the identity, enroll it, ensure it has TOTP enabled, THEN move the identity's auth policy to the MFA_enforced policy. But that's a bigger pain on the ziti operator. I'd still like to know if you could reproduce how it worked before though, it feels like this might just be a long-standing bug?
So, I went through all permutations of this.
Then, as you described - create a default ID - import into client...manually enable MFA, then enable MFA enforcement onto the identity and it works. Sorry - I had a remote engineer working on the client side, so I ASS-U-ME that this is the action that he took, and he completed that before I forced the MFA capability.
So, I will change the title of this Issue to be reflective of the issue. That is creating a MFA enabled ID does not prompt user to configure MFA upon installation of the ID, or prior to first use".
Thanks for confirming, that makes me feel better in some ways. This appears to be a codepath nobody has excercised until now but it's proving tricky to find and fix. I am hoping to get it sorted soon so that it'll work like the Mac ZDEM does (I DID confirm the ZDEM works properly).
Thanks - Just tried it with my Sons MacBook, and it correct - it works as expected.
I have two pr's up to fix this . one for the UI: https://github.com/openziti/desktop-edge-win/pull/686
and one for ziti-edge-tunnel: https://github.com/openziti/ziti-tunnel-sdk-c/pull/882
I'll try to get a beta build out here tomorrow or monday
Hello
Unable to enroll into MFA as the client thinks it has already and prompts for TOTP code when adding a new identity into ZDEW
Steps to reproduce
Workaround: