I am trying to connect my notebook with Linux openSUSE Leap 15.5 to my Windows Server 2012 Domain Controller. No success with Yast function, no success with adcli, but there is the reason visible: “Couldn’t kerberos ticket for: Kajman@ALKAS.local: KDC reply did not match expectations” + “adcli: couldn’t connect to ALKAS domain: Couldn’t get kerberos ticket for: Kajman@ALKAS.local: KDC reply did not match expectations”.
These messages are replies to the following statement + typed password for the user Kajman (= renamed Administrator): adcli join -D ALKAS -S drop.alkas.local -H NBKastnerrMini2.alkas.local -N NBKASTNERMINI2 -U Kajman -W --os-name=“Linux Suse”–os-version=“15.5” v -R ALKAS.local -O “CN=Computers,DC=ALKAS,DC=local” --login-type=user
What is wrong, can anybody please tell me, or at least give me a clue/direction?
I found this:
I wonder if you need “ALKAS.LOCAL” rather than “ALKAS.local”.
That’s it! Many thanks - but very strange. Who could think such an effect of uppercase/lowercase?
Now the Step 2: samba and winbind.
First samba:
The same computer & system. GUI of the samba, tab Identity: Domain ALKAS, comp. name of Samba server 14 chars in length, capitals, is no DC.
LDAP tab: Admin DN - CN=Kajman,CN=Users,DC=ALKAS,DC=LOCAL
Base DN: DC=ALKAS,DC=LOCAL
In the Expert settings: User suffix - “CN=Users,” … other suffixes similar. No SSL/TLS.
Back to the LDAP tab: Use LDAP pw for Back-End & ldap URL with port :389
Admin DN: CN=Kajman,CN=Users,DC=ALKAS,DC=LOCAL
Admin password - for who? Samba admin? LDAP server admin? Why twice?
Test connection: Con. successful.
OK → Join to the domain, leads to the very stubborn error message:
Failed to join domain: Failed to find DC for domain ALKAS - The object was not found.
What object? No information.
Now Winbind: wants admin’s credentials, then the same error message is displayed.
Any idea, please?
Is this in YaST that you’re looking?
Yes, it is.
I’m going to need to take a little time to set this up, because it’s been long enough that I don’t remember all the details - unless someone else can jump in and provide some advice. I probably won’t have time to do this until this weekend. Here’s what I am able to discern from the info provided so far:
In the short term, I’d probably use something like Apache Directory Studio to verify the DN of the admin DN. I also would be inclined to use SSL/TLS, as that may well be causing an issue here (IIRC, AD doesn’t like operating over the cleartext ports, which makes sense from a security standpoint).
From the “Admin password” standpoint, it’s asking for the DN for the admin account, so it would be the LDAP (ie, Active Directory) password for the user you’ve specified - and that user (kajman) needs to be a member of the Domain Administrators group, if I remember correctly. When you’re joining the domain, AD creates a computer object, and the user needs to be a domain admin in order to do that. What it’s saying is it can’t find the Domain Controller (the DC) for ALKAS- specifically, it can’t find the AD object (over LDAP).
That error (cannot find a DC) is the most strange, because I used adcli before and after the case problem was solved, no other problems arised, and I was successful to add that notebook to my Windows domain. Indeed, if I use adcli for the test of membership, it reports that all is OK and the notebook is a member of the ALKAS domain. Apparently, I have to do something for Samba, but descriptions of the YaST configurator seems insufficient to me, and as a guy coming from te Windows “world”, I am afraid of manually changing any .conf files. (Usually, if I try to follow an instructions, I find the conf doesn’t exist, or it lays elsewhere, or the required section doesn’t exist, or the .conf file begins with a warning, tha the manual change is prohibited.) (Sorry for complaining.)
I’m in the process of setting this up, and something else occurred to me - is your Leap system using the same DNS server as your AD Domain Controller?
AD uses DNS for service location, so it could be that if the Leap system isn’t set up to use the same DNS server as the DC (which is probably the DC itself), then it may not be able to locate the SRV RR records that it needs to in order to work properly.
So in looking at this further, it looks like you’re in the samba-server YaST configuration - that sets up SAMBA on your Leap system as a domain controller, not joining another domain.
Hello Jim Henderson!
No, the samba server should connect to the Windows DC, and the Linux machine should become a member of the Windows domain named ALKAS.
AK aka alkas.
Ah, OK - so effectively a non-domain controller in the domain serving up files, authenticated by the domain controller for access.
That makes sense to me. Not sure how to do it, but now that I understand more clearly, I can see if this is a use case that the YaST configuration module is designed for, or if it has to be done some other way.
I should have some time this week to dig into it a bit further.
Many thanks, I am looking for some ideas, as I am at the end otherwise.
As I’m looking at this, it’s a little unclear what you mean by “comp.name of Samba server” - can you grab some screenshots of the two tabs and the values? (Shouldn’t be anything sensitive on those screens).
In my setup, the LDAP password back-end is disabled, so it sounds like you’ve got it enabled. One thing that stands out is that you’re using port 389, which would generally not be recommended - port 389 for LDAP is (by definition) an unsecured port, and it may be that you’re getting an error because AD wants you to use the secure port (636).
I think screenshots will definitely make the configuration options clearer for me.
The “comp. name” should be the hostname of the (planned) Samba server, which is the name of my notebook with Linux SUSE named (FQDN) “NBKastnerMini2.alkas.local”.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.