Open SteelBrian opened 3 years ago
Could you please check the logs of the Function App and share that? Those are easily accessible from the Monitor section of the Function App and is visible once the remediation script is triggered.
Hello, I have deployed CloudLAPS portal weeks before. The local account is getting created and added to administrators group. However, the password rotation is failing. On the Intune portal, under remediations, the detection status is 'with issues' and remediation status is 'Failed' and for some devices it is 'Recurred'. The event viewer on the device shows Event 14 - CloudLAPS: Forbidden, password was not allowed to be updated. What do I check further?
Hello, I have deployed CloudLAPS portal weeks before. The local account is getting created and added to administrators group. However, the password rotation is failing. On the Intune portal, under remediations, the detection status is 'with issues' and remediation status is 'Failed' and for some devices it is 'Recurred'. The event viewer on the device shows Event 14 - CloudLAPS: Forbidden, password was not allowed to be updated. What do I check further?
What is the value of UpdateFrequencyDays in your CloudLAPS FunctionApp? I set it to 1 and my scripts run every 24 hours. No issues whatsoever.
We are starting our testing on this. Is it required to have the UpdateFrequencyDays and the Intune script frequency to match? Ours is set 3 to 1 respectfully.
Hello, I have deployed CloudLAPS portal weeks before. The local account is getting created and added to administrators group. However, the password rotation is failing. On the Intune portal, under remediations, the detection status is 'with issues' and remediation status is 'Failed' and for some devices it is 'Recurred'. The event viewer on the device shows Event 14 - CloudLAPS: Forbidden, password was not allowed to be updated. What do I check further?
What is the value of UpdateFrequencyDays in your CloudLAPS FunctionApp? I set it to 1 and my scripts run every 24 hours. No issues whatsoever.
I too have the UpdateFrequencyDays set to 1. And I scheduled the to run the scripts everyday at 10:30AM. But I get the error "CloudLAPS: Forbidden, password was not allowed to be updated" in eventviewer. Error code - 14
So I just deployed this also, and I am seeing this similar condition
When I monitor what is happening in Azure. 2022-07-16T14:25:49.432 [Information] OUTPUT: Expires : 2022-07-16T14:25:49.432 [Information] OUTPUT: Not Before : 2022-07-16T14:25:49.432 [Information] OUTPUT: Created : 7/16/2022 2:25:49 PM 2022-07-16T14:25:49.432 [Information] OUTPUT: Updated : 7/16/2022 2:25:49 PM 2022-07-16T14:25:49.432 [Information] OUTPUT: Content Type : Local Administrator 2022-07-16T14:25:49.432 [Information] OUTPUT: Tags : Name Value 2022-07-16T14:25:49.432 [Information] OUTPUT: AzureADDeviceID c543940b-9f57-4f16-ab64-a20d8a3b7041 2022-07-16T14:25:49.432 [Information] OUTPUT: UserName ITservicedesk 2022-07-16T14:25:49.432 [Information] OUTPUT: DeviceName LMS-5CD728CJCH 2022-07-16T14:25:49.432 [Information] OUTPUT: 2022-07-16T14:25:49.432 [Information] OUTPUT: 2022-07-16T14:25:49.474 [Information] OUTPUT: Successfully committed secret to vault
Provided the screenshots
Any progress here? I'm experiencing same issue. Event ID: 14 Running PS manually and it doesn't even create admin account for me. Error message in Visual studio run as admin, "NotAllowed"
It may has something to do with all the error message i get when i try to move the Script into Intune?
Any progress here? I'm experiencing same issue. Event ID: 14 Running PS manually and it doesn't even create admin account for me. Error message in Visual studio run as admin, "NotAllowed"
It may has something to do with all the error message i get when i try to move the Script into Intune?
Hey Espen94,
I did figure out my issue. I was creating our local admin account using OMA-URI and I found that once I created that account during Intune enrollment that the requirement to "user must change password on first login" was causing my instance of CloudLaps to fail repeatedly. So since the script creates the account I decided to stop creating my local admin account with OMA-URI, the only thing I am using OMA-URI is to place that local account into the Administrator group, then I am letting CloudLaps create and store the first password.
Using monitor in Azure as I enroll my machines I can see each time that script and schedule task run on a machine, that the passwords are being checked and rotated successfully.
The above is me manually kicking off the scheduled task and then I can see the passwords updated in the Azure CloudLAPS portal.
So at this time I have a 100% success rate with this.
Hi Trekvagabond, Thanks for fast reply! It seems like i have a different issue, since the remedation script isn't able to create user at all, i have also tried to manual create it without checking any of the boxes. I'm not sure how to get this detailed log you posted over, but i tried setup Log Analytics and it only gives me error; "'summarize' operator: Failed to resolve table or column expression named 'CloudLAPSClient_CL'..." It wont show any data, it might be because i don't get far enough for it to report anything maybe?
Any other ideas what i could do?
Kind Regards, Espen Osland
Hi Trekvagabond, Thanks for fast reply! It seems like i have a different issue, since the remedation script isn't able to create user at all, i have also tried to manual create it without checking any of the boxes. I'm not sure how to get this detailed log you posted over, but i tried setup Log Analytics and it only gives me error; "'summarize' operator: Failed to resolve table or column expression named 'CloudLAPSClient_CL'..." It wont show any data, it might be because i don't get far enough for it to report anything maybe?
Any other ideas what i could do?
Kind Regards, Espen Osland
My recommendation is to remove that instance of CloudLAPS and start from scratch seems something isn't right. I don't know enough about CloudLAPS not a developer on it, but perhaps starting from scratch and carefully following those instructions you may find your issue.
I have sadly tried 2 go through the setup at least 5 times already, it seems like there is either something with the remedation script or access in our tenant. I did enable the "$SendClientEvent = $true" for the log analytics but in the event log i get another error: "CloudLAPS: Failed to send client event to API. Error message: The remote server returned an error: (403) Forbidden."
Any progress here? I'm experiencing same issue. Event ID: 14 Running PS manually and it doesn't even create admin account for me. Error message in Visual studio run as admin, "NotAllowed" It may has something to do with all the error message i get when i try to move the Script into Intune?
Hey Espen94,
I did figure out my issue. I was creating our local admin account using OMA-URI and I found that once I created that account during Intune enrollment that the requirement to "user must change password on first login" was causing my instance of CloudLaps to fail repeatedly. So since the script creates the account I decided to stop creating my local admin account with OMA-URI, the only thing I am using OMA-URI is to place that local account into the Administrator group, then I am letting CloudLaps create and store the first password.
Using monitor in Azure as I enroll my machines I can see each time that script and schedule task run on a machine, that the passwords are being checked and rotated successfully.
The above is me manually kicking off the scheduled task and then I can see the passwords updated in the Azure CloudLAPS portal.
So at this time I have a 100% success rate with this.
My issue was addressed and resolved. You shouldn't have the remediation script and the password rotation set to different days. This will cause the error I stated before. From this comment, I am not sure you are receiving the error I was stating, but as for running it manually I have had little support or success even doing that. The best way to test it is to open up the locks on the key vault to allow your Azure admin account to see the keys and their logs. That way you can see what is going on or if it's rotating. Other than that, you can try and scan through the key vault events to identify the problem children. Best to keep it to a VERY small testing pool so you don't scan through a lot. Sorry, this response may not be as helpful as you'd like but it's best to keep that testing small, frequencies daily, and change something and check back in the morning. Note: During testing keeping the frequency low and pool small is a MUST the cost on this service is EXTREMELY high and having any clients over a hundred would put your monthly costs in the couple thousand if not more. So four or five at best would be my recommendation and let your higher-ups know your test may cost more per machine than your rollout :). "friendly advice of the day"
When I run the remediation script on my test computer I get the Password rotation failed error code, how do I fix that?
In the event log I get this: CloudLAPS: BadRequest, failed to update password CloudLAPS: Calling Azure Function API for password generation and secret update CloudLAPS: Azure AD device identifier: xxxxx CloudLAPS: Local administrator account password rotation started