Authenticating against AD domain

English Network/Internet
1

Hi all,

I’m trying to setup my OpenSUSE 12.1 virtual machine to authenticate
against the departmental Windows Active Directory.

The AD server is Windows 2008 R2.

Things are setup as follows :

AD Server : cookoo.stats.warwick.ac.uk
Windows domain : STATISTICS

I’ve setup my /etc/krb5.conf (using YAST) as follows :

[libdefaults]
default_realm = COOKOO.STATS.WARWICK.AC.UK
clockskew = 300

[realms]
COOKOO.STATS.WARWICK.AC.UK = {
kdc = cookoo.stats.warwick.ac.uk
default_domain = STATS.WARWICK.AC.UK
admin_server = cookoo.stats.warwick.ac.uk
}

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.stats.warwick.ac.uk = STATS.WARWICK.AC.UK
.STATS.WARWICK.AC.UK = COOKOO.STATS.WARWICK.AC.UK
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
external = sshd
use_shmem = sshd
}

However whenever I try and run kinit I am getting the error message :

kinit -V test

Using default cache: /tmp/krb5cc_0
Using principal: test@COOKOO.STATS.WARWICK.AC.UK
kinit: Realm not local to KDC while getting initial credentials

Any idea what I’m doing wrong ?

Cheers.

Phill.

2

With both this and a few other similar threads, I wonder if people have actually tried joining the AD using YAST first?

All these attempts to manually configure are subject to so many ways to go wrong…

BTW - I do wonder a bit what you really mean by “authenticate against” – Generally the easiest way to access Domain resources is to join the Domain, but it’s certainly possible to not join the Domain and then either manually authenticate with each and every attempt to access a Resource or configure settings for each connection.

Also, see Carlos’ recent similar thread where he determined you have to disable zeroconfig when configuring network security manually… No detailed explanation but it can be assumed that manual and automatic configurations would then possibly conflict and over-ride.

TS

3

On 2012-03-10 22:36, tsu2 wrote:
>
> With both this and a few other similar threads, I wonder if people have
> actually tried joining the AD using YAST first?

Yes, YaST does setup this very nicely, downloading and configuring all the
required bits and ends. There are several things to be done.

> BTW - I do wonder a bit what you really mean by “authenticate against”
> – Generally the easiest way to access Domain resources is to join the
> Domain, but it’s certainly possible to not join the Domain and then
> either manually authenticate with each and every attempt to access a
> Resource or configure settings for each connection.

Absolutely. As a matter of fact, I authenticated to the domain (which
requires you know the domain administrator password to join the machine to
the domain), but I could not use the shares. I did not investigate more,
but we may try this week again, dunno.

And joining a domain is not an operation easy to reverse, if you also want
to use that Linux machine in a normal way later.

It is possible, and easier perhaps, to simply use the needed resources when
needed and authenticate as required.

> Also, see Carlos’ recent similar thread where he determined you have to
> disable zeroconfig when configuring network security manually… No
> detailed explanation but it can be assumed that manual and automatic
> configurations would then possibly conflict and over-ride.

Actually, I do not know what are the manual steps to be done. I noted that
YaST changed a lot of things, some with kerberos, some with pam.d, some
with samba…

As you say, if the Windows domain is called something.local, it does not
work if zeroconf is running, it has to be disabled, or the domain renamed
(which is not a trivial task, the Windows domain has to be re-done from
scratch). I assume that with a different name than .local it works.

Curiously enough, the reverse (doing a W. Domain with Linux as the server)
has unknown caveats. I used something.localnet, and the name turned to be
too long, had to be shortened: samba complained in the log about once per
second. I renamed to something.lnet and it worked, after doing some tricks
more. If someone is interested, I’ll post the details another day.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

4

Am curious what issues you ran into (leaving a Windows Domain), what changes need to be made on the client machine. For the most part, leaving a Domain is mainly a Domain Admin task, disjoining and if desired purging AD records, not a client-side issue. I should think the main issue for the the Localmachine User is to logon with a Local Machine account, not a Domain User account.

It is possible, and easier perhaps, to simply use the needed resources when
needed and authenticate as required.

But, it’s a big headache to configure individual connections, so unless the connections are very temporary and few, it’s not recommended

> Also, see Carlos’ recent similar thread where he determined you have to
> disable zeroconfig when configuring network security manually… No
> detailed explanation but it can be assumed that manual and automatic
> configurations would then possibly conflict and over-ride.

Actually, I do not know what are the manual steps to be done. I noted that
YaST changed a lot of things, some with kerberos, some with pam.d, some
with samba…

As you say, if the Windows domain is called something.local, it does not
work if zeroconf is running, it has to be disabled, or the domain renamed
(which is not a trivial task, the Windows domain has to be re-done from
scratch). I assume that with a different name than .local it works.

Curiously enough, the reverse (doing a W. Domain with Linux as the server)
has unknown caveats. I used something.localnet, and the name turned to be
too long, had to be shortened: samba complained in the log about once per
second. I renamed to something.lnet and it worked, after doing some tricks
more. If someone is interested, I’ll post the details another day.

Actually, Windows Domains <can> be renamed but can be an enormous chore, and in certain situations it’s also possible to create a Domain alias (alternative name) and depending on what you mean by “from scratch” is probably not the case (The process of Domain renaming involves breaking down and rebuilding a significant amount of AD, but does not necessarily mean loss of structure or data). AFAIK a dotLocal Domain suffix should not ordinarily be a problem except and unless there is a zeroconfig conflict/bug as you describe.

Also, AFAIK shorter names are required only for backwards compatibility with NT4/older SAMBA which should not be implemented nowadays. If your logs are complaining, I’d look for an option that disables backwards compatibility.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

HTH,

TS.

5

On 2012-03-11 21:56, tsu2 wrote:
>
> robin_listas;2447354 Wrote:

>> And joining a domain is not an operation easy to reverse, if you also
>> want to use that Linux machine in a normal way later.
>>
>
> Am curious what issues you ran into (leaving a Windows Domain), what
> changes need to be made on the client machine. For the most part,
> leaving a Domain is mainly a Domain Admin task, disjoining and if
> desired purging AD records, not a client-side issue. I should think the
> main issue for the the Localmachine User is to logon with a Local
> Machine account, not a Domain User account.

At the client side the login is different, it uses a different pam module
(I don’t remember the name). You can also login locally to the Linux
machine, but it has a “different” appearance at GDM. I can not describe it
better.

I’ll be using that machine on Monday, I can have a look then (I’m taking a
training course). What I did was to compare configuration files on that
machine to another one that was not joined to a W.domain, and undo the
changes. I have used the same machine to create a Domain to which Windows
machine connected, so I needed that undoing.

Separating a Windows 7 client machine from a domain can also be difficult:
mine crashed so badly I had to reinstall it.

>> It is possible, and easier perhaps, to simply use the needed resources
>> when needed and authenticate as required.
>>
> But, it’s a big headache to configure individual connections, so unless
> the connections are very temporary and few, it’s not recommended

Nautilus should remember the credentials for the session. But you are
right, it can become a nuisance.

> Actually, Windows Domains <can> be renamed but can be an enormous
> chore, and in certain situations it’s also possible to create a Domain
> alias (alternative name) and depending on what you mean by “from
> scratch” is probably not the case (The process of Domain renaming
> involves breaking down and rebuilding a significant amount of AD, but
> does not necessarily mean loss of structure or data). AFAIK a dotLocal
> Domain suffix should not ordinarily be a problem except and unless there
> is a zeroconfig conflict/bug as you describe.

I had to do this several times these days, in the training course I’m
taking. To undo the domain we run “dcpromo.exe”, but on the 15 machines
that we are using it crashed on about a third and we had to reinstall
Windows server again. In fact, I have an image of Win 2008 R 2, with the AD
role installed, without configuring it (dcpromo not run). I did the image
with partimage to another partition, so that I can get to that point faster.

I didn’t know about the alias trick. Interesting.

> Also, AFAIK shorter names are required only for backwards
> compatibility with NT4/older SAMBA which should not be implemented
> nowadays. If your logs are complaining, I’d look for an option that
> disables backwards compatibility.

Could be that, I know little about samba. I thought that it was trying to
use netbios names, which are shorter.

I was trying several configuration changes. First I tried using Yast samba
server module, no go. Then I attempted a howto designed for Ubuntu that my
partners were using (and failing). No go. So I returned to YaST.

I was initially attempting to see the shares in Nautilus and using them,
and then in Windows 7. I noticed the long name problem (about one entry in
the log per second about this problem), so I shortened it (from
carloser.localnet to carloser.lnet (it wanted carloser.localn)). No go.

Then I noticed entries in the log referring to the older names I had used
in the test: so I stopped samba (smb, nmb and winbind?), deleted all
temporary files *.tdb, restarted samba and… it worked instantly! At least
I could see the domain in both Nautilus, a W7 machine running inside Vmware
player, and also at the machines from my partners.

Partial success! :slight_smile:

So I tried to join the W7 machine to the domain. I did not found how, that
was somebody else in the group. It was documented in the samba wiki: a
hotfix from Microsoft has to be applied (it is interesting that M$ does
publish patches to solve problems with Samba), and then 2 changes to the
windows registry.

Success!

We all could join our W7 virtual machines to our domains, and then logged
in (I am the only one using openSUSE, the rest are using Ubuntu or Kubuntu).

All this took the entire afternoon, from 16 hours to 20 hours. A joint
effort of 15 people, including the teacher (he is a Windows chap, but Linux
interests him).

(if you think that 15 AD domains in a single room is a nightmare,
then consider when we practice with dhcp. The entire center goes
nuts, “they” can not browse internet. I can not imagine why! ;-P)

Of course, it makes difficulties for us as well. Once I had
strange problems with my domain. It came out that I was
getting DNS from another windows domain machine, not mine :slight_smile:

What we have not done is adding kerberos or ldap to the mixture, we don’t
know how. I have noticed in my Linux firewall that W7 client is querying
the master on the LDAP port. I guess that SLES does have an integration
module for all this.

(A clarification: this training I mention it is not a school for
the young. It is for adults. Training for possible employment.
I can’t be considered young any longer. I wish I were :slight_smile: )

Next week we’ll try asterisk, I think. I still have to get a SIP client
that works in gnome with Pulse. I have one on 14.1, but it is broken in
12.1 :frowning:

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)