AD FS Event UserId - what is it?

  • Last Post 17 January 2018
kool posted this 30 December 2017

ADFS audit events 1200 and 1202 contain a UserId element. It looks like a base64 encoded string. If I decode it, it just looks like gibberish. It is much too long to simply be the user UPN or another simple identifier. Does anyone know what the UserId element is? Is there a way to extract the user name or UPN?

If I crank up auditing to Verbose I can get user ID info from the 500 and 501 events, but that level of auditing is very noisy. I'd rather avoid it if I can get the user ID from one of the Basic audit level events.

The only docs I've found on this are at and it really doesn't go into much detail about the contents of the individual events. For the most part they are self-explanatory but the UserId has me baffled.



Forum info:
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
bdesmond posted this 30 December 2017

I just looked at an ADFS server here and it has domain\username in that field....



kool posted this 02 January 2018

Thanks Brian,

We are using Shibboleth as the claims trust provider. Perhaps ADFS is putting something different into UserId when a non-AD CTP is employed. But what is it? Here is one example from a 1202 event:
That looks like a base64-encoded string. If I decode it I get this (sorry about the formatting, need to use a constant width font to view properly):

PS > [Convert]::FromBase64String("AAdzZWNyZXQxUpIEvoY3jsd5wCcaat7Am5UXIQXAnPll8iXMTo3gDXu1uGNW/PukytCnFkF96N4y6pYiJ/Hg/V
8BN8YZu3e5fUTAHP2up+bZex/BFKb6+Zqb7FgZCl50MTu/sb98k5dM8CM3En+ap+j56fAEa5HT6BkO/KvTE1J/iby8bmb8") | Format-Hex

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 00 07 73 65 63 72 65 74 31 52 92 04 BE 86 37 8E ..secret1R’.¾†7Ž
00000010 C7 79 C0 27 1A 6A DE C0 9B 95 17 21 05 C0 9C F9 ÇyÀ'.jÞÀ.!.Àœù
00000020 65 F2 25 CC 4E 8D E0 0D 7B B5 B8 63 56 FC FB A4 eò%ÌNà.{µ¸cVüû¤
00000030 CA D0 A7 16 41 7D E8 DE 32 EA 96 22 27 F1 E0 FD ÊЧ.A}èÞ2ê–"'ñàý
00000040 5F 01 37 C6 19 BB 77 B9 7D 44 C0 1C FD AE A7 E6 _.7Æ.»w¹}DÀ.ý®§æ
00000050 D9 7B 1F C1 14 A6 FA F9 9A 9B EC 58 19 0A 5E 74 Ù{.Á.¦úùšX..^t
00000060 31 3B BF B1 BF 7C 93 97 4C F0 23 37 12 7F 9A A7 1;¿±¿|“—Lð#7.š§
00000070 E8 F9 E9 F0 04 6B 91 D3 E8 19 0E FC AB D3 13 52 èùéð.k‘Óè..ü«Ó.R
00000080 7F 89 BC BC 6E 66 FC ‰¼¼nfü

The first two bytes don't correspond to a BOM that I'm familiar with and the rest looks like binary other than the "secret1". That short string kind of implies an encryption of some kind, but what? The SAML token coming back from Shib is not encrypted (other than the SSL transport wrapper). The SAML token is also much longer than this 133 bytes. Does anyone have any ideas as to what UserId contains in this case and what encryption/encoding is being used?




kool posted this 17 January 2018

Following up, I finally got this figured out. I traced a login session using FF SAML Tracer and saw that the 120x events' UserId is the SAML NameID element which is a sub-element of the Subject element. The thing that had thrown me off was I thought that UserId was coming from a SAML attribute (a.k.a. claims).

Shibboleth by default emits NameID values with the format urn:oasis:names:tc:SAML:2.0:nameid-format:transient which is indeed an opaque, per session value.

I requested that our Shib emit a NameID that maps to our UW-NetID value. This is a standard but optional NameID format in our installation of Shibboleth. Now I get a UserId value in the 120x events that is a UW-NetID name which is exactly what I wanted to enable logging user logons.

I might write up a blog post on this.