We are using Redemption in an unattended non-interactive service to receive and send mails over Exchange mailboxes. This proved to very stable with on-premise installations but we're facing some stability problems from time-to-time when using this with Exchange Online/O365.
One part of this thing seemed to be the used logon method. We've found out that forcing Basic authentication provided the most stable experience. We did this using LogonHostedExchangeMailbox or using a dedicated Outlook profile and disabled Modern Authentication using the appropriate registry keys (EnableADAL=0 and DisableAADWAM=1 for the new WAM authentication method). Now with Basic Authentication finally being disabled for all Microsoft365 tenants we're wondering what would the best method for unattended use:
LogonHostedExchangeMailbox uses basic auth when used with mailbox credentials. One can supply an OAuth Token for the password parameter as well, but this is not an option if there is no way to get an OAuth token unattended/programmatically.
With modern Windows versions Microsoft 365 apps use the Web Account Manager (WAM) for logon. When creating a dedicated Outlook profile to persist the login, using the profile with Redemption running as Windows service (but identity of the user who is owning the profile) doesn't work non-interactive. It works when run as interactive program. Use of WAM can be disabled using registry keys DisableAADWAM (see links below).
With older windows versions or when disabling WAM the Active Directory Authentication Library (ADAL) is used for modern authentification. When creating a dedicated profile using Outlook and persist the OAuth login, using this profile with Redemption initially works very well running as non-interactive service. But over the time this proved to be not stable enough, sometimes not being able to reconnect to M365 e.g. after reboot without manual intervention. Sometimes it simply helped to open Outlook with the target profile for the non-interactive service to be able to connect again (sometimes with or sometimes without having to sign in again using the OAuth login workflow).
So what would be the best option to use for unattended non-interactive service use?
Some Reference:
https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/administration/disabling-adal-wam-not-recommended
https://learn.microsoft.com/en-us/microsoft-365/enterprise/modern-auth-for-office-2013-and-2016?redirectSourcePath=%252fen-us%252farticle%252fHow-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517&view=o365-worldwide
https://www.ugg.li/office-365-auf-windows-rds-server-ist-ploetzlich-nicht-lizenziert-und-das-office-anmeldefenster-verschwindet-einfach/
Related
If you only use Outlook to connect to Exchange Online then you don’t
need to worry, as long as you are using Office 2019 or Office 2019 Pro
Plus you’ll be fine come October 2020.
Quote link
I am using Outlook version 2101 from Microsoft 365. I am not using custom API's, but I still see Outlook using basic authentication. For example, I pulled four log entries that occurred with using Outlook. Log details:
Application: Office 365 Exchange Online
Client App[1]: Offline Address Book
Client App[2]: MAPI Over HTTP
Client App[3]: Autodiscover
Client App[4]: Exchange Web Services
All 4 client applications fail to support modern authentication, which will fail when basic authentication ends. What do the users of Outlook at my company need to do to suspend using basic authentication? I have been attempting to enforce MFA but cannot get past Outlook continuously prompting users for their login credentials.
Solution:
Check org setting for modern authentication. This must be turned on before MFA will work properly. You can also enable security defaults in the Azure portal, but this approach does not allow you to selectively enroll users into MFA.
Open Microsoft 365 admin center
Show All
Settings
Org Settings
Modern authentication
Turn on modern authentication for Outlook 2013 for Windows and later
This setting allows for multiple exceptions, which will support your organization to continue to use basic authentication while you transition to modern authentication.
With this setting in place, you can selectively enforce Office 365 MFA on users. Each user will have to rebuild their locally installed Outlook profile before being able to use Outlook.
I am having an workstation specific Kerberos issue and hope anyone here would have additional recommendation.
Our application has an application server and web server and we have kerberos configured on both application layer and web layer.
And for certain users, when we provide the Kerberos link and they are not able to authorize in. And we found out the issue is workstation specific. And on the same problematic workstation, the user could access application server via Kerberos authentication.
And on the web logic we see the following error:
[SpnegoFilter.doFilter] Although user authentication to xxx was successful, Integrated Authentication could not extract the user's credentials because it appears delegation was either not configured or disallowed
I am looking for any of Windows setting could potential lead to this issue? We check that our domain is trusted on both working and nonworking machines on the browser level and GPO settings are the same.
What you're describing is unconstrained delegation, which is the act of a user handing the remote server their TGT so the server can impersonate the user without restriction.
Windows deems this as incredibly dangerous (it is) and is moving towards disabling it outright when certain security services are enabled on the client. Specifically Credential Guard. It will also block it for users that are members of the Protected Users security group, though the fact that it's affecting specific workstations leans towards Credential Guard.
If it is the above issues the correct solution is to switch to constrained delegation.
I'm working on deployment of multiple VMs' on Azure platform. I'm having problem authenticating without web interactive Login. I'm going through authentication using service-principal. However as soon as i try to run a 'azure vm list' for instance, I get a message: The server failed to authenticate.
P.S. I could create VM using interactive login. However this way does not work for the automated deployment. I'm the owner, admin of the Trial azure subscription.
I am guessing, you are using ASM instead of ARM. Unfortunately, for Azure CLI, service principal only work for ARM. See this issue in GitHub.
Luckily, there is an alternative for this. you can use azure account download or click https://manage.windowsazure.com/publishsettings to download a publish settings profile. And then, use azure account import <the file name> to login.
Notice that similar to service principal, publish settings profile only work for ASM. Microsoft Azure encourages you to use ARM instead of ASM, hence I suggest you to switch to ARM. Service Principal is Role-Based Access Control. That provides extra security. And, ASM is retiring, which means new service will only available in ARM.
Since version 5.50 the Bitvise SSH Server allows connected client to authenticate to Windows user account without providing this user's Windows password. See here: https://www.bitvise.com/ssh-server-version-history
I've checked it myself - it does indeed.
My question is of pure curiosity: what kind of sorcery is this? Is there any WinAPI that allows such thing or is this some kind of clever hack? I always thought it is impossible to impersonate as other user without a password (as even when configuring Windows service or scheduled task to "run as user" it is neccessary to provide one).
IIRC, the SSH server in Cygwin does the same thing.
If you have the appropriate privileges you can create an access token with ZwCreateToken, no password required. Such a token has some limitations. For example, you can't access network resources without a password and some encrypted material isn't accessible.
There's an explanation and some sample code here.
Since version 5.50, Bitvise SSH Server comes with a Windows authentication package. An authentication package can enhance the Windows logon process in custom ways. When the SSH server needs to log you in, but does not have a password (e.g. because you logged in with a public key), it calls the authentication package to construct a logon token which closely resembles the logon token that would have been created by Windows. As arx has noted, a session created this way does not contain your authentication credentials, so side effects are that you can't access things like network resources and EFS.
Here's what I want to do:
a program that listens in the network for a message, and when that message is received, if the user is not logged in (for example the computer just powered on and windows displays the classic login screen), it automatically logs in a certain user accordingly to the message. the username and password are known and stored safely inside the computer in a configuration for the program i'm talking about.
What I had in mind was a windows service that starts with the computer and also listens to those messages, and if one is received, then it does it's job
but I have no idea of where to start
(basically i'm trying to login a user without having to type the password, which I said is stored and known - need something mostly like the fingerprint software windows 7 comes with, and the ones that you had to install in vista/xp so that fingerprint login would work (fingerprint was only an example) )
There's two methods to pursue depending upon which operating system you're looking to run under.
For Windows XP, Windows 2000, and Windows Server 2003 you need to create a GINA.DLL. This is a replacement DLL which must follow specific rules which handles the authentication process. In your case your replacement DLL would be known by the service which was listening for your start signal, and it would make a call into the DLL with the username and password as appropriate.
MSDN Magazine article on customizing GINA.DLL
MSDN entry on GINA
For Windows Vista/7 and above you'll need to look into the Credential Provider API.
MSDN Magazine article on Credential Provider API in Vista.
MSDN entry on Credential Provider API
You can use windows auto logon feature to do this.
Create a service which waits for the required data on a network socket. Make sure this service is started after the network service (Tcpip). Modify winlogon service properties (manually) so that it depends on your service. By depends, I mean that winlogon service is started after your service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon to 1
Once you receive the data on your network socket, set the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword
Once the registry settings are in place, then the winlogon service can read those values and proceed with the login process.
For more details on setting the registry values refer: http://support.microsoft.com/kb/315231
I want clarify a little the suggestion of Vikram.exe.
Of cause the usage of AutoAdminLogon seems native for the problem, but saving of the password in registry as a clear text under HKLM\...\Winlogon\DefaultPassword is not good. Since Windows 2000 it is supported the usage of the secrets DefaultPassword which makes the same effect as the DefaultPassword registry value (see Protecting the Automatic Logon Password for the code example).
Another way to force user login or to do any other actions on the login screen is switching to the Winlogon desktop (full name WinSta0\Winlogon). You can use SwitchDesktop and SetProcessWindowStation to do this (see Window Stations and Desktops). If the service run under System account you will have all rights to do this. Depend on the configuration of your service it could be also needed to use SetTokenInformation with TokenSessionId to change the current session id. After the service process will run on the WinSta0\Winlogon desktop you can use functions like FindWindow and other GUI API to place any information in controls of the window (user name, password and so on) of other process. So you can implement more complex scenarios.
Firstly let me just say im not 100% sure how to fully complete such a application but I have a few tips.
you will need to create a Windows Service that starts during the Pre-Login, you can create a service in C#, An example of creating a C# Service is linked below:
http://msdn.microsoft.com/en-us/library/zt39148a(VS.80).aspx
Within your application you would set the property Startup Type to Automatic, This will automatically start your service on boot.
You should know that windows services run under a secure context by account so you will have to get your service to run with privs do do this.
In your Service Properties you can Click Log On and you can
To specify that the service uses the Local Service account, click This account, and then type the following NT AUTHORITY\LocalService.
To specify that the service uses the Network Service account, click This account, and then type the following NT AUTHORITY\NetworkService.
As your trying to do this remotly you will have to look at WMI (Windows Management Instrumentation) and you will be able to start/stop and send commands to your service.
Your service then would send a command to the Login Management (Not Sure of the name).
you may also wish to check this WOL class which will switch the computer on remotely as long as it supports Wake On LAN, If this is for a corporate environment then I advise you to check your network cards to make sure they are supported
http://www.codeproject.com/KB/IP/wolclass.aspx
I know of some education software that I use for schools that's called CC4 ( http://www.rm.com/shops/rmshop/story.aspx?cref=PS1026195 ) and we can do exactly what you need within this system, I'm not fully sure of how it works fully but i believe it takes the same principles described above.