I have two Ubuntu 20.04 LTS servers which updated Samba to version 4.13.17 last night. This morning users were not able to login from a some Windows 10 PC's. The same user could login from another Windows10 PC.
The Event log on the affected PC's give a Kerberos error (translated with Google Translate).
The Kerberos client received a KRB_AP_ERR_MODIFIED error from server "dd-02a$". The target name used was DD-02A$. This indicates that the target server was unable to decrypt the token provided by the client. This can occur when the target server principal name (SPN) is not registered with the account that the target service is using. Make sure the target SPN is only registered with the account used by the server. This error can also occur if the password for the target service account does not match the password that is configured in the Kerberos KDC (Key Distribution Center) for the target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified and the target domain (DD.LAN) is different from the client domain (DD.LAN), check if there are server accounts with the same name in these two domains, or use the fully qualified name to identify the server to identify.
There must be some setting on the working PC's which I need to apply to the others, but what could it be? I googled for hours this morning already without success.
I tried with a fresh Windows 10 installation in a VM and it worked until I applied the latest Windows Updates. Then it gave the same Kerberos error.
Edit: Just to add the content of /et/krb5.conf
[libdefaults]
; default_realm = ATHENA.MIT.EDU
default_realm = DD.LAN
; for Windows 2008 with AES
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
Edit2: yesterday evening there were a few more updates
libkrb5-3:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libgssapi-krb5-2:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-dnsutils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), bind9-host:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), dnsutils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), libkdb5-9:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libk5crypto3:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), krb5-locales:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), krb5-user:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libkadm5srv-mit11:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libkrb5support0:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libgssrpc4:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-utils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), bind9:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), libkadm5clnt-mit11:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-libs:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12)
At first the 2 test VMs worked after removing them from the domain, deleting the machine accounts and re-joining them to the domain. It even worked after a reboot. But minutes later I had the same problem again.
We have the same issue here.
Update 20230127:
Ubuntu published today samba 2:4.13.17~dfsg-0ubuntu1.20.04.5 source package in Ubuntu, which revert all security bug fixes from samba 2:4.13.17~dfsg-0ubuntu1.20.04.4. With this update the login works without the workaround below.
For Ubuntu 20.04 with Samba 4.13.17 there seems to be only a workaround to solve the login problem:
Modifying the Local Security Policy -> Local Policies -> Security Options -> Network security: "Configure encryption types allowed for Kerberos" Check only DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5.
This worked for us to login again.
You can configure this via GPO but the GPO will only be applied if the connection to the AD works again. So you need first a local account on the affected computer, modify the security settings and reboot the system.
You can also apply the following registry entry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"SupportedEncryptionTypes"=dword:00000007
Here are some more informations:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1993934
https://bugzilla.samba.org/show_bug.cgi?id=15197
https://launchpad.net/ubuntu/+source/samba/2:4.13.17~dfsg-0ubuntu1.20.04.5
Downgrade samba to previous version (4.11.6), as workaround without any configuration changes, works. Now clients can log on to domain.
A new samba update fixed the problem by reverting the previous security fixes.
https://ubuntu.com/security/notices/USN-5822-2
We also experienced the same issue on a VM with a DC. We switched back to a backup from November 2022. After leaving and rejoining the domain, clients worked again.
Related
What I am trying to do:
We have a Task Scheduler that kicks off an EXE, which in the course of its runtime, will connect to SQL Server.
So that would be:
taskServer.myDomain triggers the Task Scheduler action
taskServer.myDomain exe runs locally
taskServer.myDomain initiates a connection to sqlServer.myDomain
The scheduled task is associated with a service account (svc_user) that is set to run with highest privilege, run whether the user is logged in or not, and store credentials for access to non-local resources.
The actual behavior
What we are seeing is the Task Scheduler is indeed running as svc_user. It triggers the EXE as expected, and the EXE is also running as svc_user. When the EXE initiates a connection to SQL Server, it errors on authentication.
Looking at the Event Viewer we can see the failure trying to initialize the connection to SQL
Exception Info: System.Data.SqlClient.SqlException
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(System.Data.ProviderBase.DbConnectionPoolIdentity, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SqlCredential, System.Object, System.String, System.Security.SecureString, Boolean, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SessionData, System.Data.ProviderBase.DbConnectionPool, System.String, Boolean, System.Data.SqlClient.SqlAuthenticationProviderManager)
And then looking at the SQL Server logs we can see the root of the issue
Logon,Unknown,Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Could not find a login matching the name provided.
The connection initialized by the EXE to SQL Server is trying to authenticate as ANONYMOUS LOGON.
What I have tried
Background
This issue popped up when our IT team started deploying a GPO lockdown in our environments. So in order to get to this point, we first had to add some GPO exceptions to allow the svc_user to:
log on locally
log on as batch job
Progress?
This is where we started being able to capture the ANONYMOUS LOGON error in SQL Server. From there we tried a handful of other GPO exceptions including
Allow Credential Save
Enable computer and user accounts to be trusted for delegation
The actual issue?
So it would appear that this is a double hop delegation issue. Which eventually led me here and then via the answer, here and here.
So I tried adding GPO policies to allow delegating fresh credentials using the WSMAN/* protocol + wildcard.
Two issues with this:
the Fresh credentials refer to prompted credentials while the EXE is running as a service during off-hours and inheriting the credentials from the TaskScheduler
the WSMAN protocol appears to be used for remote PowerShell sessions (via the original question in the serverfault post) and not SQL Service connections.
So, I added the protocol MSSQLSvc/* to the enabled delegation and tried all permutations of Fresh, Saved and Default delegation. (This was all done in Local Computer Policy -> Computer Configuration -> Administrative Templates -> system -> Credentials Delegation)
Where it gets weird
We have another server, otherServer.myDomain, which we setup with the same TaskSchedule. It is setup with the same GPO memberships, but seems to be able to successfully connect to SQL Server. AFAIK, the servers are identical as far as setup and configuration.
The Present
I have done a bit more digging into anywhere I could think that might offer clues as to how I can feed the credentials through or where they might be falling through. Including watching the traffic between the taskServer and the sqlServer as well as otherServer and sqlServer.
I was able to see NTLM challenges coming from the sqlServer to the taskServer/otherServer.
In the case of taskServer, the NTLM response only has a workstationString=taskServer
On otherServer, the NTLM response has workstationString=otherServer, domainString=myDomain, and userString=svc_user.
Question
What is the disconnect between hop 1 (task scheduler to EXE) and hop 2 (EXE to SQL on sqlServer)? And why does this behavior not match between taskServer and otherServer?
So I finally have an update/solution for this post.
The crux of the issue was a missing SPN. The short answer:
Add an SPN for sqlServer associated with the service account SQL services are running as (not the svc_user)
example: SetSPN -S MSSQLSvc/sqlServer.myDomain myDomain\svc_sql_user
Add another SPN like above but w/ the sql service port
example: SetSPN -S MSSQLSvc/sqlServer.myDomain:1433 myDomain\svc_sql_user
Set the SQL service user account to allow delegation like so
I have IBM Db2 10.5.8 on Win10 - I've been using it for many months.
Today, I start the DB2 Command Line Processor and issue the db2start command and I get this error message: SQL1397N The DB2 service failed to logon.
I google, and find out this explanation of the error. I thought maybe the credentials expired for my db2inst local userid, so I check them, I can login to that account with no issues.
I run db2admin setid db2inst mypass just to be sure - no luck.
Stumped, no idea why it fails to login?! Some kind of post vacation syndrome.
Maybe you have already solved this problem but this link helped me.
Change the password for db2admin in setings-->control panel-->administrative tools-->computer management-->users then reboot your computer.
Also, go to Control Panel\System and Security\Administrative Tools\services and update password for DB2 service (i.e DB2 - DB2COPY1 - DB2-0). It's on "Log On" tab.
Other cause might be that you need to activate your db2 license.
Go to local and users groups (lusrmgr.msc)
On Users browse db2admin click properties and
Uncheck Account is disabled click ok
then run db2start
https://i.stack.imgur.com/ESkI7.png
Case:
For a couple of months now I've been following various tutorials, documentation and examples but somehow my end result always ends up not working like in any of the tutorials.
What I need to do is set up an active directory using Samba 4.0 on an Ubuntu Server 16.04 LTS. The samba should use a ldap-backend that is running on another Ubuntu Server 16.04 LTS. Windows clients will use the lan to login to the domain with ldap accounts.
A bonus would be to have a master-master connection from that ldap server to another ldap server, but since I already succeeded in doing something similar like that I will focus on the problem of setting up the Samba with Ldap backend.
I'm getting pertty frustrated since even though I follow tutorials and read a lot about the subject, it somehow never ends up in the result in which I can actually login to the domain, be it a samba account, be it ldap. The only thing close to this is that I at some point was able to login with a unix account, but no active directory services at that time.
Documentation that I followed:
https://help.ubuntu.com/lts/serverguide/samba-ldap.html
https://wiki.samba.org/index.php/Samba,_Active_Directory_%26_LDAP
https://help.ubuntu.com/lts/serverguide/samba-dc.html
https://www.techrepublic.com/article/how-to-configure-ubuntu-linux-server-as-a-domain-controller-with-samba-tool/
Steps performed:
Used servers:
- cloud.smoothalicious.info
- router.smoothalicious.info
- monfig.smoothalicious.info
In this order:
Installed ldap on both cloud and router. After which I implemented replication services succesfully. Cloud is the master (producer) and router is the slave (consumer). After this I imported the samba scheme and added the samba indices on the master ldap (cloud). Although replication was succesfull before, it failed with the samba indices without any error messages in syslog, auth.conf or any logs of ldap. Manually I added the indices on my own, giving up on replication at that time.
On monfig I installed Samba 4.0 and used the samba provision tool to configure it. Although I could finally find the active directory through a Windows 10 client, I could not login to it with a samba user account which I added to the domain.
The above steps are that of my previous setup, the new one follows.
Since this obviously was a big bust I decided to start over with a new tutorial. This was just setting up a Samba AD with a ldap-backend. (source: https://www.unixmen.com/setup-samba-domain-controller-with-openldap-backend-in-ubuntu-13-04/) This time I got as far as populating the ldap tree with smbldap-populate, which was succesful. Unfortunatly I was not able to find those groups with getent group. The error I get is:
nss_ldap: failed to bind to LDAP server ldapi:///cloud.smoothalicious.info: Can't contact LDAP server
Side note:
I don't seek answers, although they are welcome. I seek a tutorial that I can follow that does not end in me having different results that the tutorials shows me, even though I followed it in the detail <- this is frustrating, and it happens a lot.
LDAP backend for samba 4 is not supported:
https://wiki.samba.org/index.php/FAQ#Do_Samba_AD_DCs_Support_OpenLDAP_or_Other_LDAP_Servers_as_the_Back_End.3F
there's some work being done with it but it's far from being ready for production.
lot of people is asking for it but it seems that samba devs adopted a make-all-other-systems-acomodate-to-me approach.
I'm totally new to Oracle and have been tasked with setting up 12c for a class a professor is teaching next semester. He wants the students to be able to use their AD accounts to access the database they'll be working on. I looked at available options, and without extending the AD schema, kerberos looked to be my only option.
I tried following a combination of these:
http://www.ateam-oracle.com/configuring-your-oracle-database-for-kerberos-authentication/
https://docs.oracle.com/database/121/DBSEG/asokerb.htm#DBSEG9646
In terms of the Oracle documentation above, my process is breaking down on step 8. After step 7 (which I performed on a domain controller), when I attempt to login to SQLPLUS with SYSTEM account, I was receiving:
ORA-12641: Authentication service failed to initialize
If I try to connect with the SYSTEM (or Active Directory) account through SQL DEVELOPER I get this:
Listener refused the connection with the following error: ORA-12505, TNS:listener does not currently know of SID given in the connect descriptor
So I added NTS back to SQLNET.AUTHENTICATION_SERVICES, but the problem persists. On top of that, Enterprise Manager Express (https://:5500/em) is also no longer accessible.
This same thing happened the first time I tried stepping through the available documentation, and I managed to get everything back to a default by deleting sqlnet.ora, listerner.ora and starting from scratch... But now I'm back in the same place again.
If it is helpful, here are the contents of sqlnet.ora:
#
SQLNET.KERBEROS5_KEYTAB = c:\Windows\oracle.keytab
SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS)
SQLNET.KERBEROS5_CONF = c:\Windows\krb5.ini
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = oracle
SQLNET.KERBEROS5_CC_NAME=OSMSFT:
ADR_BASE = D:\app\oracle\product\12.1.0\dbhome_1\log
#
I did comment out SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS) which I allowed me to login with the built-in accounts again, and brought Enterprise Manager Express back up.
Any guidance on this is greatly appreciated. Thanks!
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I'm trying to install SQL Server 2008 development server on my local machine as administrator.
During the installation I receive this error, any idea how to solve it?thanks
[Error Message]
The credentials you provided for the SQL Server Agent service are invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
[Details]
Microsoft.SqlServer.Configuration.Agent.InputValidationException: The credentials you provided for the SQL Server Agent service are
invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
Use the credential that you use to login to PC. Username can be searched by Clicking in sequence
Advanced -> Find -> Choose your Username -> (e.g. JOHNSMITH_HP/John)
Password must be same as your windows login password
There you go !!
I solved using as credential built-in accounts as the NetworkService
this article point me out in the right direction
http://www.sqlcoffee.com/SQLServer2008_0013.htm
Under the "Account Name" Drop Box choose Browse.
Type the user name that you used to log in to windows on the
"Enter the object name to select" and then click "Check Names".
Click "Ok".
Under "Password" just type the password that you used for windows login.
In my case it was more of a Microsoft bug, than an actual issue. I installed under the Administrator login and used strong password btw but I was still getting this error constantly.
I tried to install with Windows credential without entering the password, but that did not go through either. Was getting the same error.
Then I cleared all password textboxes manually and copies the correct password in each text box. Hit enter, and it went through.
The error was most likely misleading.
There seem to be several problems that can cause this symptom. To tell them apart, one needs to look in the setup log files in %PROGRAMFILES%\Microsoft SQL Server\[versionnumber]\Setup Bootstrap\Log, probably Detail.txt.
According to this article, when running the installer as a local administrator and trying to use a domain account for the service, it may claim that the credentials are invalid because the local administrator does not have sufficient permissions in the domain to look up the service account's SID. This was the main problem I was encountering, and it might be what was affecting the original poster a year and a half ago.
I've had this error as a result of trying to use a cloned VM that had the same SID as the domain. The two options to fix it were: sysprep (or rebuild) the database server OR dcpromo the DC down and back up to change the domain SID.
I found I had to be logged in as a domain user.
It gave me this error when I was logged in as local machine Administrator and trying to add domain service account.
Logged in as domain user (but admin on machine) and it accepted the credentials.
In my case password was expired. Change the password and try the step again.
Well I have been battling to understand why, when at the Account section of the installation of a second node, the system will not accept the password I used to log in. I have been scratching my head - reading every post under the sun all to no avail.
I did notice that some service accounts were given as service.instname.instno#FDNdomain.com and others were given as DOMAIN\service.instname.instno (the latter being the Win2000 version)
I also noticed comments about strength of password so I thought - I can do that so I changed the password to a much higher strength and RDC in to the server - with new password and thought - best to update the services on the existing node first. I stopped the service, clicked on password and pasted in from the clipboard - (can't go wrong eh?) ha ha says Windows.. Got ya.. it wouldn't accept the password - that I just logged in with. I clicked on browse to select the service account and VOILA! the account name changed to the DOMAIN\user version and readily accepted the password. I then repeated the exercise on the other service. I then found that the node installation would continue (after backing up and forward through the process) to pick up the new name format and accepted the passwords without complaint.
I think the moral of this experience is to use the wizards and select through the "browse" button rather than manually entering the service name.
I hope my experience saves someone else the pain I went through.
Still Confused
I had a domain account with a strong password, but it didn´t work, then I used Network Service account. I tried to change it on SQL Server Configuration Manager after installation and it worked.
Taking SQL Server cluster role offline-Online on node 1 worked for me.
I had a VM that was server 2012 and I had to change the nic to VMXNET 3. It wasn't connecting to the domain fast enough for the services to start I guess.
the button 'Use same account' below thee main window will fill in all the textboxes automatically. this worked fpr me.
You might encounter one of these three problems:
Password Policy Violation, find valuable information here: https://msdn.microsoft.com/en-us/library/ms161959.aspx
Password not starting with a "character"
Domain Service User's account might be locked.
A blog post with the summary for all three possible problems might be found here:
https://cms4j.wordpress.com/2016/11/29/0x851c0001-the-credentials-you-provided-for-the-sqlserveragent-service-is-invalid/