I am trying to connect my openSuSE 13.1 machine to my Windows Server 2012 R2 AD server. I have already set everything up, and the machine is found as a computer on the server, so I know that it connected to the server properly. When I go to log in, I select my domain from the list on the login screen, type in my username and password. When I try to log in, I get the message “login failed”. I can still contact the server with my Windows Clients, so I know that the ADDS Server is still running properly. I also know it is not the firewall because I temporarily disabled it to make sure. I get the same message with it off as I do with it on.
Does anyone have any ideas as to what could be causing this?
When you say you have ‘set everything up,’ does that include Samba? Are you sure that you are sending the login details in the encoding Windows expects?
I used the YaST tools to set up the domain integration… I was under the assumption that it set everything up for the integration correctly. I have seen some articles online that just show the YaST configuration. Is there something else I have to do besides using the Windows Domain Membership applet in YaST?
It reminds me issues I had with NT4 domains and openSUSE because nmb wasn’t up and running at boot. But as you are using an AD domain you shouldn’t need NetBIOS name resolving to locate the domain controller. So, I suspect a bad value for the security global parameter in the smb.conf configuration file of the openSUSE box.
I fear that YaST tools set up a NT4 domain membership, not an AD domain membership. To be sure, you should check the smb.conf of the openSUSE box. An AD domain membership must have the global parameter security set to ads. If it’s set to domain, your openSUSE box is configured for a good old NT4 domain.
Thank you for your response. I just verified that the security is set to ADS. I just verified that the openSUSE machine can find the domain controller using ping, and it can find it without a problem.
On Sun, 15 Dec 2013 16:36:02 +0000, vader95 wrote:
> Hi Kalten,
>
> Thank you for your response. I just verified that the security is set
> to ADS. I just verified that the openSUSE machine can find the domain
> controller using ping, and it can find it without a problem.
Make sure the time is in sync. AD’s Kerberos (and Kerberos in general)
requires the time be set properly, or the authentication won’t succeed.
You might also check the server’s logs to see if there’s any indication
of what went wrong.
I made sure the time was in sync, and it was. I also checked the error logs on the server and nothing is showing as a problem. I don’t even see any attempted logons from the openSUSE machine. In fact, the only error that exists is that the AD server can’t replicate to my backup server (which is to be expected as my backup server is offline for maintenance right now). To me, it doesn’t seem like there is enough time for the openSUSE machine to even try to get to the server. As soon as I hit enter, it says logon failed. I know the user name and password are good on the network, I am using them right now on the Windows machine I am using. I selected the domain (HCR) from the list, but I’m wondering if it isn’t actually trying to use the domain.
On Sun, 15 Dec 2013 19:16:02 +0000, vader95 wrote:
> I made sure the time was in sync, and it was. I also checked the error
> logs on the server and nothing is showing as a problem. I don’t even
> see any attempted logons from the openSUSE machine. In fact, the only
> error that exists is that the AD server can’t replicate to my backup
> server (which is to be expected as my backup server is offline for
> maintenance right now). To me, it doesn’t seem like there is enough
> time for the openSUSE machine to even try to get to the server. As soon
> as I hit enter, it says logon failed. I know the user name and password
> are good on the network, I am using them right now on the Windows
> machine I am using. I selected the domain (HCR) from the list, but I’m
> wondering if it isn’t actually trying to use the domain.
>
> Thank you all for your help so far.
Maybe try tracing the connection with wireshark to see what’s going on on
the wire.
On 2013-12-14 18:26, vader95 wrote:
> Does anyone have any ideas as to what could be causing this?
There is a note about AD in the release notes. AD support was removed
from SAMBA:
+++······················
5.3. Samba Version 4.1
Samba version 4.1 shipped with openSUSE 13.1 does not include support to
operate as an Active Directory style domain controller. This
functionality is currently disabled, as it lacks integration with
system-wide MIT Kerberos.
······················+±
But you are not setting up a domain controller, but a client.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I hadn’t used wireshark in over a year, thanks for the idea. Unfortunately, I can see no traffic coming out the openSUSE box from trying to log in. I did see a bunch of ARP requests trying to reach my backup domain controller, so I finished the maintenance on it and brought it back online. No change for the login attempt, though. That is really weird
Do you think this is causing the issue? I was under the impression that since it was just a client, everything would work without problems. The server is hosted on a Windows Server 2012 R2 (first domain controller and GC) and a Windows Server 2008 machine (Secondary and GC).
I notice that the Unix and Linux Administration Handbook recommends
encrypt passwords = true
before
passdb backend =
but this is not present in the sample smb.conf on my system.
The man pages say:
encrypt passwords (G) This boolean controls whether encrypted passwords will be negotiated with the client. …
MS Windows clients that expect Microsoft encrypted passwords and that do not have plain text password support enabled will be able to connect only to a Samba server that has encrypted password support enabled …
The use of plain text passwords is NOT advised as support for this feature is no longer maintained in Microsoft Windows products. If you want to use plain text passwords you must set this parameter to no.
My configuration didn’t have it either, so I added it. Alas, it did not work.
What is odd to me is that it had to use the correct user name and password to connect into the domain in the first place. When I go to the server, I see the workstation added, so it must have accepted my administrator user name and password when I first authenticated to the server (to connect to the domain in the first place).
On Sun, 15 Dec 2013 21:56:01 +0000, vader95 wrote:
> hendersj Wrote:
>>
>> Maybe try tracing the connection with wireshark to see what’s going on
>> on the wire.
>>
>>
> I hadn’t used wireshark in over a year, thanks for the idea.
> Unfortunately, I can see no traffic coming out the openSUSE box from
> trying to log in. I did see a bunch of ARP requests trying to reach my
> backup domain controller, so I finished the maintenance on it and
> brought it back online. No change for the login attempt, though. That
> is really weird
That is strange…though a BDC isn’t something that you use in a pure AD
environment (as I recall, Microsoft even discontinued support for NT4
domains in AD on server 2012 - ISTR that you can’t set the domain
functional level to W2K any more, but I might be wrong on that).
You might try switching it over entirely to Kerberos authentication and
see if that helps.
It’s not an official “Backup Domain Controller” it is considered a global catalog (sorry, that is just its purpose as a backup server). As far as I know, the lowest functional level you can have in a 2012 R2 domain is 2008. I don’t even think a 2003 functional level is supported any more.
It is- HCR.local… I had read reports of mDNS causing issues with it, so I thought I had disabled it. I’ve never head of avahi… how do I go about disabling it?
I just found out another interesting tidbit to this mystery. If I go into the Windows Domain Membership applet and remove my computer from the domain, it does so successfully. It asks for my user name and password to write onto the server (as expected), and it removes the computer from the server just fine. I can also re-add it to the domain with the user name and password just fine, so there does not seem to be a problem communicating with the server except for at logon.
On 2013-12-16 01:16, vader95 wrote:
>
> robin_listas; Wrote:
>>
>> Perchance, is your domain named “something.local”? Because it will not
>> work. You have to stop avahi in that case.
>>
>
> It is- HCR.local… I had read reports of mDNS causing issues with it,
> so I thought I had disabled it. I’ve never head of avahi… how do I go
> about disabling it?
ARGGGHH!
Well, you stop it as any other service.
systemctl stop avahi-daemon.service
systemctl disable avahi-daemon.service
systemctl status avahi-daemon.service
I don’t know what side effects it may have, but if your AD login works,
go for it. The real solution is rename your domain as something else - I
use “something.lnet”. But changing the name of an existing AD network is
an absolute nightmare.
YaST should warn about this when you configure things. I wrote a
bugzilla about the issue years ago.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
