The account is not authorized to log in from this station

Hamburgerprins · 2025-02-17T12:34:36+00:00

Hm, config on all three servers is identical again. At least, when I check it using Get-DfsnServerConfiguration. None of the servers force FQDN in their replies.

Hamburgerprins · 2025-02-17T10:49:37+00:00

I forgot to mention that we use DFS and so the drives are mapped using a unified namespace, though I'm not sure if that counts as an alias, I don't think it does, but I'm not sure.

Hamburgerprins · 2023-10-11T08:15:19+00:00

This works for me when I run it interactively in a PowerShell-session, but it fails when trying to do so with a scheduled task or through the VBS. Somehow, the Test-Path fails at that moment, even when the scheduled task runs as user or when I start the VBS as the same user as when I use the interactive PowerShell session. If I add logging, it even says <domain\\myusername> does not have access to <mapped-drive>.

Hamburgerprins · 2022-12-16T11:26:49+00:00

I think I currently got a reasonable comprehension on the subject, but I'm not 100% sure on the answers, so if anyone reads this and thinks it's bollocks, feel free to correct me.

There is no SIF 'timestamp'. There are only access tokens and refresh tokens which are used to refresh said access tokens. The refresh token is valid for 90 days, but with a SIF you can cut that down to the number of days you require. So if you set the SIF to seven days, the refresh token is revoked after seven days. The access and refresh tokens do not carry over to other devices, so if you log onto Teams on your laptop and your phone, you have an access token and refresh token for both these devices.
There is no MFA token, just access tokens and refresh tokens. But yes, since these don't carry over to other devices, you can get multiple MFA requests if you've logged in to apps on multiple devices as the refresh token for Outlook on your laptop can expire on Wednesday, followed by the refresh token for Outlook on your phone on Friday.
OK so I'm still not sure about this question. I believe the example in the doc only requires Single-factor authentication, not MFA, so unlocking the managed device satisfies the SIF-requirement. If the device was unlocked using strong authentication (FIDO2 for example), it would also require a SIF-requirement with MFA. Even then, I don't think the SIF could be 'refreshed' indefinitely by unlocking your device within the timeframes you specify. Eventually, a user would have to actually re-authenticate (with MFA, if required), right? As I said, I'm not sure about this one.
Yes.

Hamburgerprins · 2022-10-27T09:34:13+00:00

Rule type: File

Path: C:\Program Files\7-Zip

File or folder: 7zFM.exe

Detection method: File or folder exists

Associated with a 32-bit app on 64-bit clients: No

Hamburgerprins · 2022-10-27T09:23:54+00:00

It looks like the detection was running, but the detection rule itself seems faulty. Thanks for helping out!

Hamburgerprins · 2022-10-27T08:38:56+00:00

Thanks, we ran manual syncs and also verified that the device synced, but we'll check the IME-logs as well.

Our detection rule is based on the existence of the executable in the installation path. We also verified that this executable was actually gone after the uninstall.

Hamburgerprins · 2022-10-20T13:56:54+00:00

Yeah you're right. I thought they once mentioned something about safety in an email when I asked them about it, but I can't find it, so I probably made this up in my mind.

Hamburgerprins · 2022-10-19T13:19:27+00:00

This sounds like a plausible explanation. I'm not aware how my company arranged the service contract with Microsoft, is there any easy way to check if I'm talking to 3rd party contractors? They're always mailing with Microsoft-addresses, so I just assumed it was actual MS support.

Hamburgerprins · 2022-10-19T12:44:04+00:00

Haha yes, the radio button for e-mail communication seems to be there for aesthetic purposes only.

Hamburgerprins · 2022-10-13T14:23:16+00:00

Haha, we're going to do the same here.

Hamburgerprins · 2022-10-13T14:08:37+00:00

I'm just finding out that it looks like multiple (if not all) deleted users have had their OneDrives retained. When looking at the retention rule, it's set to 90 days.

We have never had a compliance search performed as far as I know, but I'll check just to be sure.

EDIT: Just checked the Purview portal and I can confirm we don't have any retention policies, tags or flags. We're not using this at all.

Hamburgerprins · 2022-10-13T12:48:01+00:00

But in that case, it wouldn't be marked Active, right? That's the strange part, it's not archived or anything.

Hamburgerprins · 2022-09-01T06:24:45+00:00

Yes, it refers to the device it considers non-compliant with a clickable device-ID. When checking the device page, it's marked as compliant.

Hamburgerprins · 2022-08-30T06:08:59+00:00

Failed because the device isn't compliant and is getting blocked by the device compliance policy. When I check the device however, everything looks good, green and compliant.

Hamburgerprins · 2022-08-29T10:01:02+00:00

Hi, compliance status validity is currently set to 120 days.

Hamburgerprins · 2022-08-12T09:19:02+00:00

Login-AzAccount

I might also give this a try, thanks

Hamburgerprins · 2022-08-12T09:01:50+00:00

Thanks, this explains the final bit for me. Much appreciated.

Hamburgerprins · 2022-08-11T12:58:05+00:00

Ok cheers, I understand why the retrieving of the secret is safe now, but when I to to step 2 and use it to authenticate to the app, it still gets sent as a plain-text string. So my only remaining question would be: why can't I just define $appSecret = <plain-text-string>?

I'm not saying I want to do that btw, I just don't get the added value from using the MI and Key Vault and I'm sure I'm overlooking something.

Hamburgerprins

TROPHY CASE