Testing joining linux to a Windows 2008 domain with AD

Hi,

As I have the chance to play both sides of the fence, I’m trying to join
a 12.1 openSUSE machine to an AD runing in Windows 2008 server. We
control of the entire network, and we are the IT personnel in training,
lets say. The “entire network” consists of one windows 2008 machine and
one linux machine, plus one virtual Windows 7 machine, and one router.

So I fire the Windows Domain Membership module in YaST. It simply can
not join the domain!

We do not find any error event in the windows log, apparently the
user/pass is accepted.

I’m following the documented method:


> http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/cha.security.ad.html

I have tried with firewall down, or set to internal, and internal not
protected.

I find instructions in
http://community.spiceworks.com/how_to/show/1958 for doing it manually.

Apparently, the first step is matching the clocks:


> linux:~ # ntpdate antonaca-servidor.antonaca.local
> Error resolving antonaca-servidor.antonaca.local: Name or service not known (-2)
> 20 Feb 18:50:32 ntpdate[3602]: Can't find host antonaca-servidor.antonaca.local: Name or service not known (-2)
> 20 Feb 18:50:32 ntpdate[3602]: no servers can be used, exiting
> linux:~ # ^C
> linux:~ # host antonaca-servidor.antonaca.local
> antonaca-servidor.antonaca.local has address 192.168.2.106
> antonaca-servidor.antonaca.local has address 192.168.59.1
> antonaca-servidor.antonaca.local has address 192.168.232.1
> linux:~ #

The windows machine is indeed running the clock service, so my guess is
that the windows time service is not an standard NTP service. What a
surprise. I have been unable to locate (google) information on how to
enable such a service in Windows, only about how to synchronize windows
with an external server.

I have to set the time in my linux machine with an external NTP service,
and hope that the Windows machine does the same. Visually both clocks
have similar time, at lest within 20 seconds or so.

Next manual step is kerberos. The instructions I’m following say:


3  Configure Keberos by editing /etc/krb.conf

[libdefaults]
default_realm = YOUR.DOMAIN
ticket_lifetime = 24h
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
dns_lookup_realm = false
dns_lookup_kdc = true
[realms]
YOUR.DOMAIN= {
kdc = AD.your.domain:88
admin_server = AD.your.domain:749
default_domain = YOUR.DOMAIN
}

[domain_realm]
..your.domain = YOUR.DOMAIN
Your.domain = YOUR.DOMAIN



4  Test Kerberos by generating a ticket

SQUID:~# sudo kinit administrateur
Password for administrateur@YOUR.DOMAIN:
If all went well you should get a response like this:
SQUID:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrateur@YOUR.DOMAIN

Valid starting Expires Service principal
01/18/11 17:49:33 01/19/11 03:49:36 krbtgt/YOUR.DOMAIN@YOUR.DOMAIN
renew until 01/19/11 17:49:33


No go. I also try the yast module for configuring kerberos client:

Default domain: antonaca.local
Default realm: ANTONACA.LOCAL

KDC server address: antonaca-servidor.antonaca.local

Advanced settings: nothing changed.
yast configures /etc/krb5.conf. I try:


> linux:~ # kinit administrator@antonaca.local
> kinit: Cannot resolve network address for KDC in realm "antonaca.local" while getting initial credentials
> linux:~ # kinit administrador@antonaca.local
> kinit: Cannot resolve network address for KDC in realm "antonaca.local" while getting initial credentials
> linux:~ #

> linux:~ # host antonaca.local
> antonaca.local has address 192.168.2.106
> antonaca.local has address 192.168.232.1
> antonaca.local has address 192.168.59.1
> linux:~ #

So, we are stuck there.

In YaST Windows Domain Membership module, the sequence now is:

start module. Configure:


Domain: antonaca.local
X Use smb information for linux atuthentication (tried als without
ticking that)
X create Home directory on Login
X offline authentication
X Single sign-on for ssh

In expert settings, just disable “retrieve wins server via dhcp”,
because the IP is fixed. I do not know where to setup the IP of the wins
server, which is active in the windows machine. Tried both “use WINS for
hostname resolution” and not.

When I click accept, first it tries to verify domain membership, next
workgroup (why workgroup?), which takes about half a minute. Then a box
says that the host is not a member of the domain, and asks if I want to
join. I answer yes, and a “closed” window (a window sized to height
almos zero, unreadable), which I have to resize, prompts for domain user
and password. I enter them (in Spanish, Administrador, not
Administrator, but we tried both). There is also a button to obtain list
of “machine account OU”, wich returns empty. on accept, it takes a
longish time, then it fails with message: “Failed to join domain: failed
to connect to AD: operations error”. The windows event log shows no error.

This error leaves no exit way except cancel the configuration and lose
changes.

So, the main problem appears to be kerberos refusing to authenticate,
and it seems to be a Linux problem. Where do I look?

Hold on, it is working!

A colleague, intrigued by our problems, installed ubuntu live in his
windows 2008 server. Found a post saying to disable avahi, because it
interferes with .local searches.


> https://bugs.launchpad.net/ubuntu/+source/likewise-open/+bug/205236

···············.
Ubuntu (like Apple) uses Zeroconf for simple service discovery on LAN,
and this makes use of the .local domain. On the other hand, Microsoft AD
won’t work correctly if its domain name is not served by its own DNS.
Using .local for a domain name is therefore a recipe for trouble [1].

If for some reason you have to join an AD domain called
“something.local”, then you want to disable Zeroconf because the two
won’t work together. You want the .local DNS domain to be served
primarily by the Microsoft DNS and not by Zeroconf. So you edit the
/etc/nsswitch.conf file accordingly.
···············.

So, I stopped services rcavahi-daemon and rcavahi-dnsconfd, and it
worked and fast!

Our documentation doesn’t say anything about this.


Cheers / Saludos
Carlos E. R.

On 02/20/2012 07:33 PM, Carlos E. R. wrote:

> Hold on, it is working!
>
> A colleague, intrigued by our problems, installed ubuntu live in his
> windows 2008 server. Found a post saying to disable avahi, because it
> interferes with .local searches.

So, I can login as a domain user. We are using gnome, and the login
manager doesn’t work right.

There is no domain entry, contrary to what the documentation says. I
have to type “antonaca\mperez”, pass to enter. First attempt to connect
fails (for all users), and the window stops there; I have to press
cancel, then the full domain/name prompt appears as one entry more in
the list to choose from. I try with that entry, success.

The local directory is “/home/ANTONACA/username”.

Once in, I try to browse the local network: nothing is found.

I have to select “go to”, then location, and type
“smb://antonaca-servidor/Datos” and then I’m prompted for the
domain/login/paswword, which should not be needed as I’m already in the
domain. I fill the password, and it is rejected (the permission can be
forgotten instantly, remembered for the session, or for ever - in theory).

Only the administrator can browse the exported shares.

Worse, if I login as administrator, then I’m also prompted for the
password to browse files, and the password is always rejected.

Seems quite buggy to me.

I also entered a share in yast, domain config, advanced. It does not appear


Cheers / Saludos
Carlos E. R.

My initial thought is “I can’t remember joining an AD should be that hard.” I haven’t had to join an openSUSE to an AD for a couple years now, but I’d be surprised if the experience should be that different now than when I joined an 11.1.

  1. IIRC just simply running the YAST Windows Domain Membership module should automatically discover any available DCs in your network (unless a DC isn’t available, then it’s a bit trickier). Once the DC is discovered, the Domain should be automatically presented as an option for joining, and enrollment should not be different than adding a new Windows machine to your AD. I’m not sure why you’re manually configuring Kerberos, AFAIK it should automatically self-configure. Your comment about avahi being an issue in openSUSE is interesting, I had not heard about that before (and could be a new issue since 11.1), if it’s an issue then I’d consider it a bug if the openSUSE YAST Windows Domain Membership didn’t disable avahi automatically.

  2. The clock requirement is a standard Kerberos requirement (would apply to LDAP as well as AD wherever Kerberos is implemented), your client machine needs to be within something like 5 seconds of the network DCs. Ideally, you should just point NTP to a DC which is also providing NTP to ensure proper time sync, and it should work (wouldn’t know why your attempt failed).

3… WINS (NetBIOS Name Server) is an archaic requirement, a requirement only in the NT4 days or when client machines didn’t understand DDNS. Today, with the most recent versions of BIND even most contemporary Linux distros should understand DDNS.

  1. I’m not sure if you’re really trying to configure a fixed IP, I <highly> do not recommend it and it may be contributing to your problems. In a Windows AD, there is an intimate relationship where data is exchanged between the DC, DNS and DHCP. If you remove any of the three (eg DHCP) you decrease your chances of success and increase chances of problems. If you really want a fixed address, configured a DHCP Reserved Lease.

  2. Recommend you check whether <all> types of network resources are working, I assume by “browse” you only mean network share browsing. certain things may or may not be automatically available immediately. Although AD <usually> grants access based on Username tokens, <some> resources might be secured by machinename tokens or a combination thereof.

  3. Remember that joining a Linux machine to AD is not in any way the same as adding a Windows box… You’ll need to verify that your new Linux box is registered as an “other” machine in AD and of course it’s not manageable (unless you install any of those AD/Linux integration solutions). You should also verify that your box can be seen on the network as well as whether you can see other machines before trying to access resources on those machines.

HTH,
TS