opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] Qué 127.0.1.1 malo?

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] Qué 127.0.1.1 malo?
From: lynn <lynn@xxxxxxxxxxxx>
Date: Sun, 01 Apr 2012 22:41:31 +0200
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 Apr 2012 16:42:05 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4F785668.30807@antonaylward.com>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <4F749D25.7080107@steve-ss.com> <4F74AD37.4050304@antonaylward.com> <4F75950D.6020203@steve-ss.com> <4F75A8A8.9030102@antonaylward.com> <4F75CE13.6050706@telefonica.net> <4F75EA66.20304@antonaylward.com> <4F76095B.1080801@steve-ss.com> <4F7631DF.1000603@antonaylward.com> <4F76AF84.1050805@steve-ss.com> <4F76FA67.4090507@antonaylward.com> <4F772477.3080002@steve-ss.com> <4F7737F2.5000903@antonaylward.com> <4F7744CF.9030204@steve-ss.com> <4F775380.8040606@antonaylward.com> <4F77FE5C.90401@steve-ss.com> <4F785668.30807@antonaylward.com>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
*El 01/04/12 15:21, Anton *Aylward *escribió:
*lynn dijo el siguiendo en 04/01/2012 03:06 AM:
*El 31/03/12 20:57, Anton *Aylward *escribió:
*lynn dijo el siguiendo en 03/31/2012 01:54 PM:
En 03/31/2012 06:59 PM, Anton *Aylward escribió:
*lynn dijo el siguiendo en 03/31/2012 11:36 AM:




Entonces no tienes *ddns trabajando _completamente_.
*Sorry Si parezco *picky, pero somos sin duda en un *realm donde precisión
y *completeness asuntos.
No, ser tan *picky tan necesario. Lo necesito.





*KDC = *Kerberos Controlador de ámbito ?


Sí.

A correctamente mirada arriba de *FQDN de sólo una IP requiere trata el DNS correctamente
implementa inverso *lookup.  Nosotros'*ve estableció no tienes completo
y *accurate mesas inversas.

Te #poder complacer dilucidar.

No tengo inverso *lookup. La zona de delantero es creada cuándo empiezo liga. Consigue actualizado cuándo un cliente nuevo (Linux o ventanas) botas o une el ámbito. Para *ddns lo tiene un *tsig que es un *Kerberos *keytab. El *keytab fue producido cuándo el ANUNCIO era primer *provisioned. Yo *posted nombró.*conf Hace unos cuantos correos. También tengo un *static zona inversa. La cosa única que lo impide demasiado de ser incluido en el *ddns es que no sé cómo para generar un *keytab para él. Esto es donde el *Samba *guys ha cambiado el ligar *innards.

Te es corriendo ANUNCIO?  Tienes un maestro de ámbito del Microsoft que corre ANUNCIO o te
es todo Linux en el núcleo y justo clientes de Ventanas?


Sí estamos corriendo ANUNCIO. *Samba4 _es_ ANUNCIO. El *schema incluye *rfc2703. Nuestros
usuarios tienen el *posixAccount y *posixGroup objetos que son definidos en
el *m$ ANUNCIO *schema. (Hecho público *via el *Samba *vs *m$ el Tribunal europeo que gobierna
último año)

pienso que estamos hablando en cruz [los propósitos o yo necesitan un actualizar.
Pensé *SAMBA actuaba como Controlador de Ámbito y que el ANUNCIO era
el *database, posiblemente (pero no siempre) implementado por *LDAP.

ANUNCIO = Directorio Activo, un *dynamically mantuvo *database, un servicio
de directorio que carreras en el Controlador de Ámbito y DNS de necesidades, *Kerberos y *LDAP
para apoyarlo.

Pensé *SAMBA era más que justo ANUNCIO.

*Samba4 es un controlador de ámbito de las ventanas. Consiste de un totalmente Linux-*ified ANUNCIO. Tiene su propio construido en *KDC y *LDAP *server.

Pronto, tendrá su DNS propio *server también. Ya tiene su DNS laborable propio *server pero irónicamente lo trabajos únicos para delantero *ddns en el momento.



*Kerberos Necesita no sólo a *authenticate el usuario pero también las máquinas
en el *lan.
Aquello es por qué *DNS implementado* correctamente es crucial con *Kerberos.

Si el código puede no  un lleno *backward-para-*ward-*backward *verification de la
IP/*FQDN del **authoritative* (y presumiblemente asegurado) servicio
de DNS entonces el *fallback al /*etc/los anfitriones es un agujero de seguridad.  El
usuario en el control de la máquina de cliente puede poner cualquier cosa él (o ella) gusta
a /*etc/anfitriones y tan *spoof la identificación.

La Raíz única tiene acceso a /*etc/anfitriones en nuestro *lan.


Ahora la cuestión soy dejado con es esto.  Es la máquina arriba de y corriendo,
lo tiene conseguido su dirección de IP del *DHCP *server?

Sí. En este punto el *dlz parte de DNS *grabs lo. Ahora, sólo mi delantero es
actualizado así que mi zona inversa está yendo para saber nada sobre el actualizar lo es?

No sé.  En todos los sistemas he trabajado con él *boils abajo al
*DHCP *server diciendo el DNS *server.

La dirección es entregada fuera de después de la máquina de Linux es chutada, mucho tiempo antes del
*SAMBA el cliente viene arriba, así que el *SAMBA el lado de cosas tendría que tener
nada para hacer con él.  Todo este *DDNS tendría que trabajar a toda costa de la
presencia de *SAMBA, *Kerberos, *YP/NIS, o NFS.  *SAMBA No es un requisito
para HP/de AIX/de Linux/de UNIX-*UX/DG-*UX/*Solaris-las redes únicas y yo lo han tenido
corriendo en aquella clase de poner.

*Kerberos Tiene que *authenticate el *dns *server antes de que puede hacer cualquier cosa en el *lan. El *KDC es suministrado por *Samba tan *Samba tiene que ser arriba de antes de cualquier *ddns tiene lugar. Aun así podemos mostrar que los clientes tienen una IP antes de hacer un ámbito *logon cuando pueden *ping el *server en *bot IP y *fqdn (porque el *server es en su *etc/archivo de anfitriones. El perdiendo el vínculo parece para ser lo que los clientes de ventanas tienen en vez de /*etc/anfitriones.



Cómo venido el trabajo de clientes de las ventanas *OK. Qué  tienen que nosotros  no?

No sé.  No soy muy Ventanas-*savvy.

De hecho estamos suponiendo* cosas aquí.
 Tú  el vertedero de las mesas de DNS?
Cómo  yo  un vertedero?

Si vemos en aquel vertedero que los clientes de Ventanas tienen #ambos delantero y entradas
inversas sabemos están haciendo algo los clientes de Linux no
son.  Entonces y sólo entonces puede decimos que están trabajando *OK en este sentido de *OK.

correo él apenas sé qué. Entretanto estoy corriendo con el misterioso 127.0.1.1:-(
*Thanks otra vez para vuestro tiempo,
*L *x
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
para contactar el dueño, *e-correo: *opensuse+owner@xxxxxxxxxxxx


El 01/04/12 15:21, Anton Aylward escribió:
lynn said the following on 04/01/2012 03:06 AM:
El 31/03/12 20:57, Anton Aylward escribió:
lynn said the following on 03/31/2012 01:54 PM:
On 03/31/2012 06:59 PM, Anton Aylward wrote:
lynn said the following on 03/31/2012 11:36 AM:




Then you don't have ddns working _completely_.
Sorry if I seem picky, but we are definitely in a realm where accuracy
and completeness matters.
No, be as picky as necessary. I need it.





KDC = Kerberos Domain Controller ?


Yes.

To correctly look up FQDN from only a IP requires treat DNS properly
implements reverse lookup.  We've established you don't have complete
and accurate reverse tables.

Could you please elucidate.

I do not have reverse lookup. The forward zone is created when I start bind. It get updated when a new client (Linux or windows) boots or joins the domain. For ddns it has a tsig which is a Kerberos keytab. The keytab was produced when the AD was first provisioned. I posted he named.conf a few posts ago. I also have a static reverse zone. The only thing that prevents it too from being included in the ddns is that I don't know how to generate a keytab for it. This is where the Samba guys have changed the bind innards.

Are you running AD?  You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?


Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in
the m$ AD schema. (made public via the Samba vs m$ European Court ruling
last year)

I think we are talking at cross [purposes or I need an update.
I thought SAMBA was acting as a Domain Controller and that the AD was
the database, possibly (but not always) implemented by LDAP.

AD = Active Directory, a dynamically maintained database, a directory
service that runs on the Domain Controller and needs DNS, Kerberos and
LDAP to support it.

I thought SAMBA was more than just AD.

Samba4 is a windows domain controller. It consists of a totally Linux-ified AD. It has its own built in KDC and LDAP server.

Soon, it will have its own DNS server too. It already has its own working DNS server but ironically it only works for forward ddns at the moment.



Kerberos needs not only to authenticate the user but also the machines
on the lan.
That is why *properly implemented* DNS is crucial with Kerberos.

If the code can't do a full backward-for-ward-backward verification of
the IP/FQDN from the *authoritative* (and presumably secured) DNS
service then the fallback to the /etc/hosts is a security hole.  The
user in control of the client machine can put whatever he (or she) likes
into /etc/hosts and so spoof the identification.

Only root has access to /etc/hosts on our lan.


Now the question I'm left with is this.  Is the machine up and running,
has it got its IP address from the DHCP server?

Yes. At this point the dlz part of DNS grabs it. Now, only my forward is
updated so my reverse zone is going to know nothing about the update is it?

I don't know.  In all the systems I've worked with it boils down to the
DHCP server telling the DNS server.

The address is handed out after the Linux machine is booted, long before
the SAMBA client comes up, so the SAMBA side of things should have
nothing to do with it.  All this DDNS should work regardless of the
presence of SAMBA, Kerberos, YP/NIS, or NFS.  SAMBA is not a requirement
for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it
running in that kind of setting.

Kerberos has to authenticate the dns server before it can do anything on the lan. The KDC is supplied by Samba so Samba must be up before any ddns takes place. We can however show that the clients have an IP before doing a domain logon as they can ping the server on bot IP and fqdn (because the server is in their etc/hosts file. The missing link seems to be what the windows clients have instead of /etc/hosts.



How come the windows clients work OK. What do they have that we don't?

I don't know.  I'm not very Windows-savvy.

Actually we are *assuming* things here.
Did you do the dump of the DNS tables?
How do I do a dump?

If we see in that dump that the Windows clients have both forward and
reverse entries we know they are doing something the Linux clients are
not.  Then and only then can we say they are working OK in this sense of OK.

Will post it as soon as I know how. Meanwhile am running with the mysterious 127.0.1.1:-(
Thanks again for your time,
L x
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>