Sending blank username to PI from ADFS farm

[tedbear]

Hi Sbidy,

A couple of times we have experienced that a blank username, realm and transaction_id is sent to PI. I wonder if this happens on an ADFS farm if the connection is not persistent and therefore:

1. user signs in with UPN & PWD to ADFS being connected to ADFS server A
2. user posts his/her OTP code to ADFS server B

Is there a way (or maybe this is already happening) to capture the actual username also when submitting the OTP, or does this only happen on the step before reaching the OTP screen?

This probably happened 4 times during 50 logins. We are still testing with just around 15 people. We will however roll out to 18.000 users shortly (hopefully).

Best regards, Teddy

[tedbear]

Thinking of it, I don't believe the realm is stored in the session, is it? So the lost session does not explain the blank realm sent.

[cornelinux]

To my understanding the username is passed as hidden field to the login form? https://github.com/sbidy/privacyIDEA-ADFSProvider/blob/master/privacyIDEAADFSProvider/AdapterPresentationForm.cs#L50 So the username should be available. Could it be, that someone manages to enter an empty username in the first place?

[tedbear]

Not really possible, as they wouldn't then be authenticated (in order to get to the OTP step). The username canbe in two formats: userprincipalname (in our case our email address) or domain\samaccountname

[cornelinux]

So the username should be a hidden field in the login dialog. Did you check the source code of the otp login html page, if the username is actually contained? So that you can narrow down, where the username gets lost?

[tedbear]

The issue is that I cannot reproduce is, although it has been reported 4 times by my colleagues who are testing. I did verify that they entered the correct code (it is logged on our BIG-IP proxy): Normal OTP login:

Missing username, realm and trans:

I believe it happens on those webview popups (Outlook, Skype and OneDrive - the thick clients) in which you cannot see the source code. Although not consistently, as they work 9/10 times. Doing normal tests I do see the username as a hidden field, yes.

[tedbear]

In addition I have also tested every ADFS directly to filter out any faulty farm members - all of them works/have the correct code in place.

[cornelinux]

Maybe you can also log the User-Agent in the Big IP, so you can be sure, if this problem only occurs on certain clients.

[tedbear]

Unfortunately I have no proxy in front of those ADFS's (thats a long story about two separate companies sharing a 365 environment). Only in front of the PI server.

[cornelinux]

Can the big IP only log parameters? Can't you log header information of the http request?

[tedbear]

I can, but the requests to the PI is the adfs plug-in doing that, not the client :)

On 28 Dec 2018, at 11:06, Cornelius Kölbel <[email protected]mailto:[email protected]> wrote:

CAUTION: This email originated from outside the organization. Do not click on a link or open an attachment unless you recognize the sender and know the content is safe.

Can the big IP only log parameters? Can't you log header information of the http request?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/sbidy/privacyIDEA-ADFSProvider/issues/17#issuecomment-450333497, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFxgSQ2m4O4MXQoRltQoc91ctgISm9pcks5u9e0ggaJpZM4ZjmwQ.

[cornelinux]

Oh. You are right. My bad! I should have studied this system better ;-)

[sbidy]

Hey! So I try to recap the issue: In some (use)cases the username and realm field in the OTP-Auth.-Webview is empty. This behavior can not be reproduced but mostly shows up on/requests from Office client software.

In my opinion the issue occurs if the username and the "realm" are not a part of the SAML-Token/Claim. https://github.com/sbidy/privacyIDEA-ADFSProvider/blob/b58a01f00a172817691148d0f781da1584963298/privacyIDEAADFSProvider/Adapter.cs#L51 In this case the username and realm(domain) is empty and this leads to such a behavior. Please check the EventLog for errors and exceptions. In this case a event (exception) should be logged.

For debugging and testing I'll prepare a "debug" version for you, so I can get a better understanding why and where the error occurs. Additionally I'll check the interface definition from MS what exactly the identityClaim represents.

[sbidy]

Here is the debug version: Download Please use only for testing. To get/read the debug messages please use the DebugView from the Sysinternals tool set --> DebugView v4.81. The debug message prefixes are ID3A_ADFSadapter: and ID3Aprovider:.

[tedbear]

Here is the debug version: Download Please use only for testing. To get/read the debug messages please use the DebugView from the Sysinternals tool set --> DebugView v4.81. The debug message prefixes are ID3A_ADFSadapter: and ID3Aprovider:.

Thank you, sbidy. We installed the debug version on the ADFS servers yesterday - so now we wait for more failures :) Meanwhile I have seen the following in the PI audit logs:

I don't believe if it's connected to the debug version or not - but it seems to sometimes not being able to authenticate to PI.

Best regards, Teddy

[sbidy]

Hey Teddy, I can reproduce the error if I define a wrong username and password combination in the provider configuration file. Can you please check your config and the user? If you don't use the triggerChallenge features (i.e. you use only "non-tiggerd" tokens) please delete the user and the password values in the config.

In this case the DebugView should also provide the exception message: [xxxx] ID3Aprovider: System.Net.WebException: The remote server returned an error: (401) Unauthorized.

[cornelinux]

If sbidy is right and the credentials of the service account are wrong, then you should see a failed auth request in the audit log.

null

[tedbear]

We do use the trigger, as we are using SMS messages. I have verified that the user/pwd is correct on all 4 ADFS servers and I have also tested them directly one by one. I will try and dig a bit into the PI logs and see if and how the triggerchallenge auth call failed.

[tedbear]

I did have a few cases I wanted to collect log data from. But correct me if I'm wrong: I need to have the debugviewer.exe running while testing in order to collect any of the log output? Does the log data exist in the event log or in any text files? Although I have only seen two empty pass field today (but with username field filled), so this could be a user error. I have however seen quite a few run into the issue of https://github.com/sbidy/privacyIDEA-ADFSProvider/issues/19

Best regards, Teddy

[sbidy]

Yes, you must run the debugview tool in the capture mode open.

1. Start the debugview
2. Click on "Capture Global Win32" and "Capture Events"
3. Now you should see only the ADFS log output
4. Under "File" you can export/safe this file as an text log file.
5. Upload the log file here - but please obfuscate the usernames and other confidential information 😉

Unfortunately the debugview.exe must be running and in capture mode all the time. In the next release I'll update the whole provider to log some error data to the eventlog.

[tedbear]

Thank you, sbidy. I will ask my overseas colleagues to have the program running in capture mode on the servers for now and then wait until this bug occurs again (if ever).