[smb] net join et le plugin AD

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Yep. Mais je ne suis toujours pas certain que le net join ne fasse pas
double emploi.

Tu veux dire, par rapport à Open Directory ?

Voui.

Il y a double bind, en effêt, mais c'est parce que samba et OD ne savent
pas communiquer :

- samba ne peut pas déléguer l'authentification à OD :
Malgré un "auth methods = opendirectory" il lui faut un "enabled
account", c'est à dire une copie du passwd pour lui, qui ne marche que
pour les utilisateurs locaux. (sans parler du man pas à jour)

Ca, c'est normal, il faut inscrire le hash NTLM et SMBLANMANAGER dans le
fichiers qui contient les hash des utilisateurs locaux
(/var/db/shadow/hash).

- OD ne peut pas déléguer l'authentification à samba, il n'y a pas de
plugin Directory Access pour samba à ma connaissance. Si tu fais le bind
samba, OD ne sais pas y accéder pour le login ou du afp.

Ca, c'est une question de config. Pour Samba, ça ne doit pas passer par
le daemon DirectoryServices directement mais par lookupd (pour
l'identification de l'utilisateur, dans le cas où lookupd ne trouve pas,
il demand à DirectoryServices qui cherche par ses plugins dans netinfo
et ensuite dans l'AD) et les pam (ces derniers gérant
l'authentification).

Au final, il faut donc un double bind, l'un pour samba et un pour OD.

Ca me paraît quand même chelou, dans le cas d'un serveur on ne fait pas
de net join mais par contre on modifie (enfin, modifiait en 10.3.x,
c'est automatique en 10.4.x) le smb.conf pour indiquer à Samba que
c'était de l'AD, on lui donnait également le nom du serveur Kerberos.

C'est sale, mais fonctionnel.

C'est chelou mais si ça fonctionne ainsi, ne change pas :)

Apparement tu ne trouves pas la soupe à ton goût :)

Disons que je trouve qu'il y a un double bind qui me paraît étrange, il
doit y avoir moyen de faire mieux en cherchant mais comme mon AD est en
vadrouille (AD de formation) je ne peux pas tester. Si ça fonctionne, ne
change pas :)

[snip]

A noter que le "password server" ne marche pas très très bien.
On pourrait théoriquement lui en spécifier plusieurs séparés par une
virgule, et finir par * pour qu'il aille aussi partout où il peut.
Mais ensuite il est tout perdu le pauvre.

Mmmmmm, il n'a peut-être pas encore eu le temps de faire le tour de tout
le domaine, ça peut être long.

En effêt, c'est sans-doutes un des problèmes que j'avais en mettant 2
contrôleurs. Je n'attendais pas le temps de réplication pour continuer
mes tests et il était dans les choux.

Ah la réplication en AD... un grand moment de bonheur, j'ai connu, il
m'a fallu attendre 24 heures avant que tout fonctionne une fois.

[snip]

Et sans l'étape 3, ça donne quoi ? (je n'ai pas d'AD sous la main pour
faire mes tests, désolé).

Si tu mets un security = ads ou "security = domain" dans smb.conf, alors
le net join est nécessaire. Et je ne vois pas comment faire d'autre ...

Tu vois ça dans un log ?

Vu que par défaut avec "security = user" ça ne marche pas.

Normal.

Le truc c'est que après ça, les utilisateurs locaux ne sont plus
authentifiés en smb. Seuls les utilisateurs du domaine le sont.

Normal aussi, mais après tout, c'est le but, quand même.

Tien, je pourrais tester un
auth methods = sam winbind opendirectory
Puis tenter d'activer les utilisateurs locaux...
C'est très bien cette discution, ça me donne des idées :)

C'est le but, il me semble :-)

De nada, mais tu as quand même du faire une double déclaration et je ne
vois pas, dans cette procédure, quand tu importes les keytabs des
services pour l'intégration kerberos. Je pense que tu fais de
l'authentification l/p et pas kerberos depuis tes clients quand ils se
connectent à ton Mac OS X. Vois-tu, après connexion depuis un autre
poste, un ticket Kerberos au nom de cette machine ?

Oui, il y a une ligne de plus dans mon ticket.

Avec un ticket correspondant à la machine ?

Dureste, avec un ticket il m'authentifies directement et sans ticket il
me demande un mot de passe. Pour moi il n'y a pas photo, c'est bien une
authentification kerberos. "net ads join" doit être capable de faire le
nécessaire au niveau des keytabs.

net join ferait donc ce qu'il faut dans le tickets de service...
Intéressant, je n'avais pas vu ça dans la doc. Si c'est ça, la procédure
est donc impérative. Par contre, normalement, cette commande doit gérer
le fait que ta machine existe déjà et ne pas la déclarer en double.

Est-ce que tu as un fichier /etc/krb5.keytab avant et après le passage
de la commande sur une machine propre ?

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Yep. Mais je ne suis toujours pas certain que le net join ne fasse pas
double emploi.

Tu veux dire, par rapport à Open Directory ?

Voui.

Il y a double bind, en effêt, mais c'est parce que samba et OD ne savent
pas communiquer :

- samba ne peut pas déléguer l'authentification à OD :
Malgré un "auth methods = opendirectory" il lui faut un "enabled
account", c'est à dire une copie du passwd pour lui, qui ne marche que
pour les utilisateurs locaux. (sans parler du man pas à jour)

Ca, c'est normal, il faut inscrire le hash NTLM et SMBLANMANAGER dans le
fichiers qui contient les hash des utilisateurs locaux
(/var/db/shadow/hash).

C'est pas nécessaire pour le login, ni pour l'afp, ni pour le ftp, ni
pour le reste. Je ne vois pas pourquoi ce serait normal pour le smb.

Cet état de fait ne me convient pas et c'est pour ça que j'ai fait
autrement.

- OD ne peut pas déléguer l'authentification à samba, il n'y a pas de
plugin Directory Access pour samba à ma connaissance. Si tu fais le bind
samba, OD ne sais pas y accéder pour le login ou du afp.

Ca, c'est une question de config.

Non, c'est Apple qui n'a pas écrit le plugin nécessaire :)
Ils veulent se la jouer différent, ne pas utiliser pam, qu'ils aillent
jusqu'au bout ou qu'ils nous laisse la possibilité de rester dans les
standards unix.

Pour Samba, ça ne doit pas passer par
le daemon DirectoryServices directement mais par lookupd (pour
l'identification de l'utilisateur, dans le cas où lookupd ne trouve pas,
il demand à DirectoryServices qui cherche par ses plugins dans netinfo
et ensuite dans l'AD) et les pam (ces derniers gérant
l'authentification).

C'est juste mais dans ce paragraphe je parlais de l'inverse en fait.
OD n'est pas capable de consulter samba pour l'authentification ni pour
l'identification d'un utilisateur, quand bien même samba est capable de
fournir ces info.

Au final, il faut donc un double bind, l'un pour samba et un pour OD.

Ca me paraît quand même chelou, dans le cas d'un serveur on ne fait pas
de net join mais par contre on modifie (enfin, modifiait en 10.3.x,
c'est automatique en 10.4.x) le smb.conf pour indiquer à Samba que
c'était de l'AD, on lui donnait également le nom du serveur Kerberos.

Tu as une doc sur la méthode ?
Et sans tickets, ça marche aussi ?

C'est sale, mais fonctionnel.

C'est chelou mais si ça fonctionne ainsi, ne change pas :)

Mais non :
Les utilisateurs ont un single sign-on s'ils ont un ticket,
une authentification ntls sinon.
Moi, à présent que j'ai la bonne procédure, ça me prends 5 minutes pour
configurer un serveur. Et 2 comptes par serveur, tant que j'en ai pas
200, ...

Bref, c'est bien mieux que ce qu'on peut faire par défaut.
Et pour moi, ne pas stocker le hash est important :
ça n'a rien à faire là et c'est pas sécure.

Apparement tu ne trouves pas la soupe à ton goût :)

Disons que je trouve qu'il y a un double bind qui me paraît étrange, il
doit y avoir moyen de faire mieux en cherchant mais comme mon AD est en
vadrouille (AD de formation) je ne peux pas tester. Si ça fonctionne, ne
change pas :)

Le sujet m'intéresse et je suis prêt à continuer mes tests sur une
machine de test. Quand à mon serveur, s'il se montre stable il ne
bougera effectivement pas.

En effêt, c'est sans-doutes un des problèmes que j'avais en mettant 2
contrôleurs. Je n'attendais pas le temps de réplication pour continuer
mes tests et il était dans les choux.

Ah la réplication en AD... un grand moment de bonheur, j'ai connu, il
m'a fallu attendre 24 heures avant que tout fonctionne une fois.

Tu peux aussi demander manuellement aux serveurs de se répliquer.
Mais il faut y penser.

Si tu mets un security = ads ou "security = domain" dans smb.conf, alors
le net join est nécessaire. Et je ne vois pas comment faire d'autre ...

Tu vois ça dans un log ?

Non, dans la doc :
SECURITY = ADS
In this mode, [snip] Samba will need to be joined to the
ADS realm using the net utility.

Normal aussi, mais après tout, c'est le but, quand même.

Pas forcément

Tien, je pourrais tester un
auth methods = sam winbind opendirectory
Puis tenter d'activer les utilisateurs locaux...
C'est très bien cette discution, ça me donne des idées :)

C'est le but, il me semble :-)

Généralement on poste une question pour avoir une réponse.

Mais c'est vrais que c'est aussi très utile pour mettre ses idées au
clair puis pour échanger des idées et développer les points qui pausent
problème :)

Oui, il y a une ligne de plus dans mon ticket.

Avec un ticket correspondant à la machine ?

Oui

Dureste, avec un ticket il m'authentifies directement et sans ticket il
me demande un mot de passe. Pour moi il n'y a pas photo, c'est bien une
authentification kerberos. "net ads join" doit être capable de faire le
nécessaire au niveau des keytabs.

net join ferait donc ce qu'il faut dans le tickets de service...
Intéressant, je n'avais pas vu ça dans la doc. Si c'est ça, la procédure
est donc impérative.

C'est possible, il faut que je teste ça.

Par contre, normalement, cette commande doit gérer
le fait que ta machine existe déjà et ne pas la déclarer en double.

J'ai testé en "security = domain", qui fait du rpc et pas du kerberos.
Si je mettais le même nom dans Directory Access et dans samba, le bind
le plus récent l'emportait et rompait le lien de l'autre.
Je te l'ai dit : samba et OD ne savent pas se causer :)

Est-ce que tu as un fichier /etc/krb5.keytab avant et après le passage
de la commande sur une machine propre ?

Dès lors que je me logue localement avec un compte de l'AD, oui, j'ai un
fichier keytab.
Il pointe sur le nom mis dans OD, bien entendu, et non sur le nom mis
dans smb.conf.

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Ca, c'est normal, il faut inscrire le hash NTLM et SMBLANMANAGER dans le
fichiers qui contient les hash des utilisateurs locaux
(/var/db/shadow/hash).

C'est pas nécessaire pour le login, ni pour l'afp, ni pour le ftp, ni
pour le reste. Je ne vois pas pourquoi ce serait normal pour le smb.

Tout simplement pour des raisons de compatibilité.

Cet état de fait ne me convient pas et c'est pour ça que j'ai fait
autrement.

Là n'est pas la question, si tu veux utiliser les utilisateurs locaux,
tu dois avoir un hash compatible avec les méthodes d'authentification et
Samba ne prévoit rien d'autre.

- OD ne peut pas déléguer l'authentification à samba, il n'y a pas de
plugin Directory Access pour samba à ma connaissance. Si tu fais le bind
samba, OD ne sais pas y accéder pour le login ou du afp.

Ca, c'est une question de config.

Non, c'est Apple qui n'a pas écrit le plugin nécessaire :)

Tss, tss, Apple n'a jamais parlé de faciliter la vie de celui qui
utilise un Mac OS X client comme serveur. Et il n'y a pas besoin d'un
plugin OD pour Samba, tout est là. Par contre, sur la version serveur,
l'intégration se fait en quelques clics.

Ils veulent se la jouer différent, ne pas utiliser pam, qu'ils aillent
jusqu'au bout ou qu'ils nous laisse la possibilité de rester dans les
standards unix.

Tu n'as pas tout bien lu, ils utilisent aussi la bouse de pam pour les
services d'origine unix, comme samba, ftp ou ssh, par exemple. Dans ce
cas, c'est lookupd qui fait l'identification, s'appuyant éventuellement
sur DirectoryService quand ça touche des domaines qu'il ne comprend pas,
et ensuite il passe la main à pam pour l'authentification, ce dernier
s'appuyant sur le security framework au besoin.

Pour Samba, ça ne doit pas passer par
le daemon DirectoryServices directement mais par lookupd (pour
l'identification de l'utilisateur, dans le cas où lookupd ne trouve pas,
il demand à DirectoryServices qui cherche par ses plugins dans netinfo
et ensuite dans l'AD) et les pam (ces derniers gérant
l'authentification).

C'est juste mais dans ce paragraphe je parlais de l'inverse en fait.
OD n'est pas capable de consulter samba pour l'authentification ni pour
l'identification d'un utilisateur, quand bien même samba est capable de
fournir ces info.

Ce n'est pas à Samba de faire l'identification, ça fait doublon. Il peut
faire appel au système pour ça. Sauf si ton Samba est déclaré comme PDC
ou BDC auquel cas il sera interrogé.

Ca me paraît quand même chelou, dans le cas d'un serveur on ne fait pas
de net join mais par contre on modifie (enfin, modifiait en 10.3.x,
c'est automatique en 10.4.x) le smb.conf pour indiquer à Samba que
c'était de l'AD, on lui donnait également le nom du serveur Kerberos.

Tu as une doc sur la méthode ?

Oui, plein chez Apple ou d'autres, payantes ou gratuites.

Dans les docs PDF serveur ils doivent aborder le sujet. Sinon, chez
O'Reilly, le bouquin du regretté Michael Bartosh en parle. Chez
Peachpitt Press aussi, les bouquins sur les Directory Services font ça.
Enfin, on le fait en formation avec plein d'autres trucs :

<http://train.apple.com/cgi-bin/WebObjects/Registration.woa/wa/displayCo
urse?courseID=ewoJInByaW1hcnlLZXkiID0gewoJCSJjb3Vyc2VJRCIgPSAiMjIwNjUiOw
oJfTsKCSJlbnRpdHlOYW1lIiA9ICJBSVNUQ291cnNlIjsKfQ%253d%253d>

Et sans tickets, ça marche aussi ?

Ben vi.

C'est sale, mais fonctionnel.

C'est chelou mais si ça fonctionne ainsi, ne change pas :)

Mais non :
Les utilisateurs ont un single sign-on s'ils ont un ticket,

Un TGT ?

une authentification ntls sinon.

Il manque clairement quelque chose dans ton royaume Kerberos...

Moi, à présent que j'ai la bonne procédure, ça me prends 5 minutes pour
configurer un serveur. Et 2 comptes par serveur, tant que j'en ai pas
200, ...

Ben, en même temps, à force de mettre des Mac Mini comme serveur, ça va
arriver vite...

Bref, c'est bien mieux que ce qu'on peut faire par défaut.

Par défaut, ce n'est pas conçu pour.

Et pour moi, ne pas stocker le hash est important :
ça n'a rien à faire là et c'est pas sécure.

Tu arrives à le lire sans être root ?

Disons que je trouve qu'il y a un double bind qui me paraît étrange, il
doit y avoir moyen de faire mieux en cherchant mais comme mon AD est en
vadrouille (AD de formation) je ne peux pas tester. Si ça fonctionne, ne
change pas :)

Le sujet m'intéresse et je suis prêt à continuer mes tests sur une
machine de test. Quand à mon serveur, s'il se montre stable il ne
bougera effectivement pas.

Je fouille plus vite et mieux quand je suis devant la machine, j'avoue.

On en reparle dans une quinzaine, après mes vacances.

Ah la réplication en AD... un grand moment de bonheur, j'ai connu, il
m'a fallu attendre 24 heures avant que tout fonctionne une fois.

Tu peux aussi demander manuellement aux serveurs de se répliquer.
Mais il faut y penser.

On l'avait fait, nada. Lors de la réplication automatique, ça a
fonctionner.

Si tu mets un security = ads ou "security = domain" dans smb.conf, alors
le net join est nécessaire. Et je ne vois pas comment faire d'autre ...

Tu vois ça dans un log ?

Non, dans la doc :
SECURITY = ADS
In this mode, [snip] Samba will need to be joined to the
ADS realm using the net utility.

Quand on faisait la jonction automatique d'un serveur à un domaine AD,
on passait par le plugin DA et ensuite on modifiait le smb.conf, mais il
y avait d'autres trucs que simplement le SECURITY.

<http://www.macdevcenter.com/pub/a/mac/2003/12/09/active_directory.html>

Un bon résumé de la méthode et de ce qui se passe derrière.

Tien, je pourrais tester un
auth methods = sam winbind opendirectory
Puis tenter d'activer les utilisateurs locaux...
C'est très bien cette discution, ça me donne des idées :)

C'est le but, il me semble :-)

Généralement on poste une question pour avoir une réponse.

Bah, aussi pour avoir des pistes.

Mais c'est vrais que c'est aussi très utile pour mettre ses idées au
clair puis pour échanger des idées et développer les points qui pausent
problème :)

C'est aussi l'intérêt d'une conversation.

Oui, il y a une ligne de plus dans mon ticket.

Avec un ticket correspondant à la machine ?

Oui

Mais il faut d'abord un TGT... Tu es proche, il va falloir fouiller.

net join ferait donc ce qu'il faut dans le tickets de service...
Intéressant, je n'avais pas vu ça dans la doc. Si c'est ça, la procédure
est donc impérative.

C'est possible, il faut que je teste ça.

Pareil.

Par contre, normalement, cette commande doit gérer
le fait que ta machine existe déjà et ne pas la déclarer en double.

J'ai testé en "security = domain", qui fait du rpc et pas du kerberos.

Ca n'a aucun intérêt, àmha.

Si je mettais le même nom dans Directory Access et dans samba, le bind
le plus récent l'emportait et rompait le lien de l'autre.
Je te l'ai dit : samba et OD ne savent pas se causer :)

Tss tss, tu ne sais pas les apprivoiser, nuance, ça fonctionne, je le
sais, je l'ai vu. Et de mémoire, net join ne doit pas tout casser quand
une machine existe, elle doit le signaler et proposer de l'utiliser,
mais si ça force un changement du mot de passe de la machine, là, oui,
ça va tout casser, mais c'est toi qui casse :-)

Est-ce que tu as un fichier /etc/krb5.keytab avant et après le passage
de la commande sur une machine propre ?

Dès lors que je me logue localement avec un compte de l'AD, oui, j'ai un
fichier keytab.

Euh, pardon ? je te parle du /etc/krb5.keytab, pas de tes tickets
obtenus. Ce fichier contient les clés associés à chaque service, ces
clés permettent le déchiffrement des éléments envoyés par le serveur KDC
qui lui aussi doit connaître ces clés (en même temps, c'est lui qui les
a conçues, alors, il peut les connaître). Donc, si tu as ce fichier, le
service doit être déclaré en tant que tel et avoir un principal dans le
royaume Kerberos de ton AD. Sinon, tu as un soucis.

Il pointe sur le nom mis dans OD, bien entendu, et non sur le nom mis
dans smb.conf.

Gné ?

Tu l'as lu ce fichier ?

Tiens, une autre doc :

<http://www.tkk.fi/cc/docs/kerberos/sso.html#conf>

Le fichier /etc/krb5.conf dont ils parlent est le fichier
/Library/Preferences/edu.mit.kerberos sur Mac OS X (encore que si Mac OS
X trouve un /etc/krb5.conf il sache en tenir compte).

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Là n'est pas la question, si tu veux utiliser les utilisateurs locaux,
tu dois avoir un hash compatible avec les méthodes d'authentification et
Samba ne prévoit rien d'autre.

Bon, toutes mes excuses.
J'ai mal lu la doc, j'ai confondu sam et pam dans "auth methods"
Donc oui, tu as raison, samba ne sait pas dialoguer avec unix non-plus.
C'est nul ça.

Tss, tss, Apple n'a jamais parlé de faciliter la vie de celui qui
utilise un Mac OS X client comme serveur.

Oui, c'est compréhensible ça.
Mais documenter le système qu'on vends, ça semble normal par contre ...

Et puis il y n'y a pas que la doc Apple, les trucs vite et sales pour
faire du serveur pas cher, google connait.

Et il n'y a pas besoin d'un
plugin OD pour Samba, tout est là. Par contre, sur la version serveur,
l'intégration se fait en quelques clics.

Faut que j'étudies OSX serveur plus à fond, crénom. J'ai des tests à y
faire depuis des mois, toujours plus urgeant sur la liste, ... Bon, ça
viendra.

Tu n'as pas tout bien lu, ils utilisent aussi la bouse de pam pour les
services d'origine unix, comme samba, ftp ou ssh, par exemple.

Yep, sauf que pam n'est pas une bouse, c'est un standard puissant.
Sur linux, il lui manque "juste" un assistant de config gérant tout le
système d'authentification. (krb, ldap, pam et winbind entre autre)
Dureste ça existe peut-être déjà sur une distrib ou une autre.

Et comme dit plus haut, samba a de la peine avec pam en fait.
Enfin il peut, mais en cleartext. :-(

Ce n'est pas à Samba de faire l'identification, ça fait doublon. Il peut
faire appel au système pour ça.

S'il en est capable, en effêt. Reste à trouver comment.

Sauf si ton Samba est déclaré comme PDC
ou BDC auquel cas il sera interrogé.

Oui, mais c'est une question d'architecture réseau à ce moment là.
C'est pas un truc qu'on fait juste pour que samba soit content :)

Tu as une doc sur la méthode ?

Oui, plein chez Apple ou d'autres, payantes ou gratuites.

Dans les docs PDF serveur ils doivent aborder le sujet. Sinon, chez
O'Reilly, le bouquin du regretté Michael Bartosh en parle. Chez
Peachpitt Press aussi, les bouquins sur les Directory Services font ça.
Enfin, on le fait en formation avec plein d'autres trucs :

Ok. Grâce à http://safari.oreilly.com, j'ai accès au bouquin de Bartosh.
Il y a en effêt quelques chapitres à lire.
Bon, je ferai ça demain.

<http://train.apple.com/cgi-bin/WebObjects/Registration.woa/wa/displayCo
urse?courseID=ewoJInByaW1hcnlLZXkiID0gewoJCSJjb3Vyc2VJRCIgPSAiMjIwNjUiOw
oJfTsKCSJlbnRpdHlOYW1lIiA9ICJBSVNUQ291cnNlIjsKfQ%253d%253d>

Ok, j'ai lu ce dernier lien qui dis tout pareil que ma méthode à une
exception près :
"Finally, enable Windows Services using the Server Admin application or
its command-line equivelent, serveradmin."
Que j'ai remplacer par un "net bind".
Evidement, il n'y a pas de serveradmin sur Mac OS X client :)

Mais non :
Les utilisateurs ont un single sign-on s'ils ont un ticket,

Un TGT ?

Je ne distingue pas un TGT d'un autre ticket, on vois ça à quoi ?
Sinon ça resemble point pour point à ce qu'il y a sur les images du lien
que tu m'as donné. Et si ça marche, ça doit être en ordre, logiquement.

une authentification ntls sinon.

Il manque clairement quelque chose dans ton royaume Kerberos...

Selon moi, c'est en ordre :
Kerberos n'est pas connu pour accepter une config foireuse :)

Moi, à présent que j'ai la bonne procédure, ça me prends 5 minutes pour
configurer un serveur. Et 2 comptes par serveur, tant que j'en ai pas
200, ...

Ben, en même temps, à force de mettre des Mac Mini comme serveur, ça va
arriver vite...

bof ... j'en suis à peut près à un mac mini par tera, ça vas :)
Un collègue a mis un san de 140 tera, mais j'en suis pas encore là. Ouf.

Et c'est discret dans le budjet, avec ça j'ai pas besoins de me
justifier sur la présence nouvelle de mac dans la salle serveurs.

Et pour moi, ne pas stocker le hash est important :
ça n'a rien à faire là et c'est pas sécure.

Tu arrives à le lire sans être root ?

C'est une question de principe.
Etre root, c'est histoire de 3 minutes si tu as un accès physique.
Et puis j'ai pas des serveurs très sécurisés, il y a des clef ssl qui
trainent par-ci par-là à cause de mes scripts de backup, donc on ne sait
jamais. Evidement, il y a plus simple que ça pour hacker notre réseau
mais des fois qu'on tomberait sur un sportif...

Disons que je trouve qu'il y a un double bind qui me paraît étrange, il
doit y avoir moyen de faire mieux en cherchant mais comme mon AD est en
vadrouille (AD de formation) je ne peux pas tester. Si ça fonctionne, ne
change pas :)

Le sujet m'intéresse et je suis prêt à continuer mes tests sur une
machine de test. Quand à mon serveur, s'il se montre stable il ne
bougera effectivement pas.

Je fouille plus vite et mieux quand je suis devant la machine, j'avoue.
On en reparle dans une quinzaine, après mes vacances.

Bonnes vacances :)

Non, dans la doc :
SECURITY = ADS
In this mode, [snip] Samba will need to be joined to the
ADS realm using the net utility.

Quand on faisait la jonction automatique d'un serveur à un domaine AD,
on passait par le plugin DA et ensuite on modifiait le smb.conf, mais il
y avait d'autres trucs que simplement le SECURITY.

<http://www.macdevcenter.com/pub/a/mac/2003/12/09/active_directory.html>

oui : security = ads
use spnego = yes
realm = ADS.EXAMPLE.COM
workgroup = ADS

plus le truc dans serveradmin, que je serais intéressé d'analyser.

Par contre, normalement, cette commande doit gérer
le fait que ta machine existe déjà et ne pas la déclarer en double.

J'ai testé en "security = domain", qui fait du rpc et pas du kerberos.

Ca n'a aucun intérêt, àmha.

Il y a 2 intérêts :
Tu peux gérer une authentification sans kerberos
(par exemple sur des machines qui ne sont pas dans le domaine)
ou alors tu peux authentifier à partir d'un serveur NT.

Tss tss, tu ne sais pas les apprivoiser, nuance, ça fonctionne, je le
sais, je l'ai vu. Et de mémoire, net join ne doit pas tout casser quand
une machine existe, elle doit le signaler et proposer de l'utiliser,
mais si ça force un changement du mot de passe de la machine, là, oui,
ça va tout casser, mais c'est toi qui casse :-)

Yep, en fait il faut que je refasse des tests.
Dès que j'ai du temps et une autre machine de test.

Est-ce que tu as un fichier /etc/krb5.keytab avant et après le passage
de la commande sur une machine propre ?

Dès lors que je me logue localement avec un compte de l'AD, oui, j'ai un
fichier keytab.

Euh, pardon ? je te parle du /etc/krb5.keytab, pas de tes tickets
obtenus.

Ok, c'est que j'ai pensé un moment que ce fichier était généré au moment
du premier login alors qu'il est fait quand on fait le bind dans le
plugin Directory Services.

Ce fichier contient les clés associés à chaque service, ces
clés permettent le déchiffrement des éléments envoyés par le serveur KDC
qui lui aussi doit connaître ces clés (en même temps, c'est lui qui les
a conçues, alors, il peut les connaître). Donc, si tu as ce fichier, le
service doit être déclaré en tant que tel et avoir un principal dans le
royaume Kerberos de ton AD. Sinon, tu as un soucis.

Il pointe sur le nom mis dans OD, bien entendu, et non sur le nom mis
dans smb.conf.

Gné ?

Tu l'as lu ce fichier ?

[c110:~> sudo ktutil
Password:
ktutil: rkt /etc/krb5.keytab
ktutil: list
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 6 20014$@ICI.CH
2 6 20014$@ICI.CH
3 6 20014$@ICI.CH
4 6 host/20014.ad.isrec.ch@ICI.CH
5 6 host/20014.ad.isrec.ch@ICI.CH
6 6 host/20014.ad.isrec.ch@ICI.CH
7 2 host/c110.ad.isrec.ch@ICI.CH
8 2 host/c110.ad.isrec.ch@ICI.CH
9 2 host/c110.ad.isrec.ch@ICI.CH
10 2 c110$@ICI.CH
11 2 c110$@ICI.CH
12 2 c110$@ICI.CH

C'est crypté, mais ktutil sert à lire et écrire tout ça.
L'ennui c'est qu'on ne sait pas à quel service chaque élément est
attaché... faudrait que j'aille regarder sur le domaine controler tien.

Tiens, une autre doc :

<http://www.tkk.fi/cc/docs/kerberos/sso.html#conf>

Le fichier /etc/krb5.conf dont ils parlent est le fichier
/Library/Preferences/edu.mit.kerberos sur Mac OS X (encore que si Mac OS
X trouve un /etc/krb5.conf il sache en tenir compte).

Bonne idée, merci, je vais lire ça aussi :)
J'avais déjà fait un single sign-on sur linux, donc je connais un peu.
Pas facile, pour sûr. Il y a toujours un petit truc qui merde, et après
c'est la natation brassé coulé.
Pour ça, Mac OS X est cool, il fait tout bien tout seul :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Là n'est pas la question, si tu veux utiliser les utilisateurs locaux,
tu dois avoir un hash compatible avec les méthodes d'authentification et
Samba ne prévoit rien d'autre.

Bon, toutes mes excuses.
J'ai mal lu la doc, j'ai confondu sam et pam dans "auth methods"
Donc oui, tu as raison, samba ne sait pas dialoguer avec unix non-plus.
C'est nul ça.

Ah bahhhhh, tu vois, Apple ne peut pas non plus toujours être en cause
;-)

Tss, tss, Apple n'a jamais parlé de faciliter la vie de celui qui
utilise un Mac OS X client comme serveur.

Oui, c'est compréhensible ça.
Mais documenter le système qu'on vends, ça semble normal par contre ...

$ open /usr/share/swat/using_samba/toc.html

C'est livré :)

Et puis il y n'y a pas que la doc Apple, les trucs vite et sales pour
faire du serveur pas cher, google connait.

Voui, mais parfois très sale.

Et il n'y a pas besoin d'un
plugin OD pour Samba, tout est là. Par contre, sur la version serveur,
l'intégration se fait en quelques clics.

Faut que j'étudies OSX serveur plus à fond, crénom. J'ai des tests à y
faire depuis des mois, toujours plus urgeant sur la liste, ... Bon, ça
viendra.

Viens nous voir, en 8 jours on te montre plein de trucs ;-)

Tu n'as pas tout bien lu, ils utilisent aussi la bouse de pam pour les
services d'origine unix, comme samba, ftp ou ssh, par exemple.

Yep, sauf que pam n'est pas une bouse, c'est un standard puissant.

C'est un peu bouseux, quand même... C'est bien, je ne dis pas, mais
bouseux, c'est lourd à paramétrer.

Sur linux, il lui manque "juste" un assistant de config gérant tout le
système d'authentification. (krb, ldap, pam et winbind entre autre)
Dureste ça existe peut-être déjà sur une distrib ou une autre.

Jamais vu.

Et comme dit plus haut, samba a de la peine avec pam en fait.
Enfin il peut, mais en cleartext. :-(

Mouarf...

Ce n'est pas à Samba de faire l'identification, ça fait doublon. Il peut
faire appel au système pour ça.

S'il en est capable, en effêt. Reste à trouver comment.

passdb backend : opendirectorysam
auth methods = opendirectory

sjnma

Sauf si ton Samba est déclaré comme PDC
ou BDC auquel cas il sera interrogé.

Oui, mais c'est une question d'architecture réseau à ce moment là.
C'est pas un truc qu'on fait juste pour que samba soit content :)

Ben non, justement, c'est bien ce que je dis.

Dans les docs PDF serveur ils doivent aborder le sujet. Sinon, chez
O'Reilly, le bouquin du regretté Michael Bartosh en parle. Chez
Peachpitt Press aussi, les bouquins sur les Directory Services font ça.
Enfin, on le fait en formation avec plein d'autres trucs :

Ok. Grâce à http://safari.oreilly.com, j'ai accès au bouquin de Bartosh.
Il y a en effêt quelques chapitres à lire.
Bon, je ferai ça demain.

Achète-le, ça vaut le coup. Dommage que Michael soit disparu si tôt, il
lui restait tant à nous faire partager :(

Tu as aussi un document chez Bombich...

<http://homepage.mac.com/bombich/Directory_Services_1.0.pdf>

<http://train.apple.com/cgi-bin/WebObjects/Registration.woa/wa/displayCo
urse?courseID=ewoJInByaW1hcnlLZXkiID0gewoJCSJjb3Vyc2VJRCIgPSAiMjIwNjUiOw
oJfTsKCSJlbnRpdHlOYW1lIiA9ICJBSVNUQ291cnNlIjsKfQ%253d%253d>

Ok, j'ai lu ce dernier lien qui dis tout pareil que ma méthode à une
exception près :
"Finally, enable Windows Services using the Server Admin application or
its command-line equivelent, serveradmin."
Que j'ai remplacer par un "net bind".
Evidement, il n'y a pas de serveradmin sur Mac OS X client :)

Et ça n'a rien à voir :)

serveradmin, cf la doc PDF Mac OS X Server sur la ligne de commande
(<http://images.apple.com/server/pdfs/Command_Line_v10.4_2nd_Ed.pdf>),
est un outil en cli pour administrer Mac OS X Server, c'est la version
texte de l'application Server Admin.

Rien à voir avec le net join...

Mais non :
Les utilisateurs ont un single sign-on s'ils ont un ticket,

Un TGT ?

Je ne distingue pas un TGT d'un autre ticket, on vois ça à quoi ?

Bah, en général il s'appelle krbtgt.

Sinon ça resemble point pour point à ce qu'il y a sur les images du lien
que tu m'as donné. Et si ça marche, ça doit être en ordre, logiquement.

C'est pas faux :-D

Il manque clairement quelque chose dans ton royaume Kerberos...

Selon moi, c'est en ordre :
Kerberos n'est pas connu pour accepter une config foireuse :)

Oui, mais en même temps, si un client sans ticket n'arrive pas à
initialiser la procédure de demande de TGT pour obtenir ensuite un
Service Ticket, il y a un soucis quelque part. Pas dramatique, mais
dérangeant.

Ben, en même temps, à force de mettre des Mac Mini comme serveur, ça va
arriver vite...

bof ... j'en suis à peut près à un mac mini par tera, ça vas :)

;-)

Un collègue a mis un san de 140 tera, mais j'en suis pas encore là. Ouf.

Joli SAN, effectivement, ça commence à le faire.

Et c'est discret dans le budjet, avec ça j'ai pas besoins de me
justifier sur la présence nouvelle de mac dans la salle serveurs.

Bah, un bel Xserve, ça le fait aussi et c'est autrement plus costaud,
quand même...

Tu arrives à le lire sans être root ?

C'est une question de principe.

Dans ce cas, ne fais pas confiance à Mac OS X, le hash (ssha-1) du mot
de passe de tous les utilisateurs est au même endroit.

Etre root, c'est histoire de 3 minutes si tu as un accès physique.

Mmmmmmmm, ça dépend de la sécurisation de la machine. Et puis, si tu as
un accès physique à tes serveurs, il y a plus grave.

Et puis j'ai pas des serveurs très sécurisés, il y a des clef ssl qui
trainent par-ci par-là à cause de mes scripts de backup, donc on ne sait
jamais. Evidement, il y a plus simple que ça pour hacker notre réseau
mais des fois qu'on tomberait sur un sportif...

Ben, déjà, passer par des clés ssh est mieux que l'utilisation du mot de
passe.

Je fouille plus vite et mieux quand je suis devant la machine, j'avoue.
On en reparle dans une quinzaine, après mes vacances.

Bonnes vacances :)

Merci :)

Quand on faisait la jonction automatique d'un serveur à un domaine AD,
on passait par le plugin DA et ensuite on modifiait le smb.conf, mais il
y avait d'autres trucs que simplement le SECURITY.

<http://www.macdevcenter.com/pub/a/mac/2003/12/09/active_directory.html>

oui : security = ads
use spnego = yes
realm = ADS.EXAMPLE.COM
workgroup = ADS

plus le truc dans serveradmin, que je serais intéressé d'analyser.

Bah, c'est relancer Samba, en fait, tout simplement, pour que les
daemons voient le changement de configuration.

J'ai testé en "security = domain", qui fait du rpc et pas du kerberos.

Ca n'a aucun intérêt, àmha.

Il y a 2 intérêts :
Tu peux gérer une authentification sans kerberos
(par exemple sur des machines qui ne sont pas dans le domaine)
ou alors tu peux authentifier à partir d'un serveur NT.

Il doit y avoir un fallback sur du normal en-dehors de Kerberos,
normalement. Enfin, c'est comme ça avec Mac OS X Server, sauf à demander
uniquement Kerberos dans la configuration.

Tss tss, tu ne sais pas les apprivoiser, nuance, ça fonctionne, je le
sais, je l'ai vu. Et de mémoire, net join ne doit pas tout casser quand
une machine existe, elle doit le signaler et proposer de l'utiliser,
mais si ça force un changement du mot de passe de la machine, là, oui,
ça va tout casser, mais c'est toi qui casse :-)

Yep, en fait il faut que je refasse des tests.
Dès que j'ai du temps et une autre machine de test.

Oki.

Euh, pardon ? je te parle du /etc/krb5.keytab, pas de tes tickets
obtenus.

Ok, c'est que j'ai pensé un moment que ce fichier était généré au moment
du premier login alors qu'il est fait quand on fait le bind dans le
plugin Directory Services.

Il est surtout utile quand tu fais une jonction Kerberos, sur Mac OS X
Server on le fait soit manuellement (10.3), soit avec un outil dédié à
l'intégration Kerberos appelé slapconfig, qui fait plein d'autres trucs
sympathiques, cf la doc command line citée plus haut.

Tu l'as lu ce fichier ?

[c110:~> sudo ktutil
Password:
ktutil: rkt /etc/krb5.keytab
ktutil: list
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 6 20014$@ICI.CH
2 6 20014$@ICI.CH
3 6 20014$@ICI.CH
4 6 host/20014.ad.isrec.ch@ICI.CH
5 6 host/20014.ad.isrec.ch@ICI.CH
6 6 host/20014.ad.isrec.ch@ICI.CH
7 2 host/c110.ad.isrec.ch@ICI.CH
8 2 host/c110.ad.isrec.ch@ICI.CH
9 2 host/c110.ad.isrec.ch@ICI.CH
10 2 c110$@ICI.CH
11 2 c110$@ICI.CH
12 2 c110$@ICI.CH

C'est crypté, mais ktutil sert à lire et écrire tout ça.

Ok.

L'ennui c'est qu'on ne sait pas à quel service chaque élément est
attaché... faudrait que j'aille regarder sur le domaine controler tien.

Voui. On voit surtout ta machine déclarée deux fois, une fois en tant
que 20014 et une autre fois en tant que c110. Effet du plugin DA et du
net join, je pense.

Tiens, une autre doc :

<http://www.tkk.fi/cc/docs/kerberos/sso.html#conf>

Le fichier /etc/krb5.conf dont ils parlent est le fichier
/Library/Preferences/edu.mit.kerberos sur Mac OS X (encore que si Mac OS
X trouve un /etc/krb5.conf il sache en tenir compte).

Bonne idée, merci, je vais lire ça aussi :)

De nada.

J'avais déjà fait un single sign-on sur linux, donc je connais un peu.
Pas facile, pour sûr. Il y a toujours un petit truc qui merde, et après
c'est la natation brassé coulé.
Pour ça, Mac OS X est cool, il fait tout bien tout seul :)

Eh oui et c'est encore mieux en 10.4, c'est clic et clic sur le serveur
:-D

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Ah bahhhhh, tu vois, Apple ne peut pas non plus toujours être en cause
;-)

Yep. Je commence à comprendre les rumeures de différents entre les dev
de samba et du reste de la comunauté :)
Ils ont vraiment fait cuisine à part.

Oui, c'est compréhensible ça.
Mais documenter le système qu'on vends, ça semble normal par contre ...

$ open /usr/share/swat/using_samba/toc.html

C'est livré :)

$ grep -ri opendirectory /usr/share/swat

mouarf, périmée ta doc ;)

Et il n'y a pas besoin d'un
plugin OD pour Samba, tout est là. Par contre, sur la version serveur,
l'intégration se fait en quelques clics.

Faut que j'étudies OSX serveur plus à fond, crénom. J'ai des tests à y
faire depuis des mois, toujours plus urgeant sur la liste, ... Bon, ça
viendra.

Viens nous voir, en 8 jours on te montre plein de trucs ;-)

Oui, évidement.
J'aurais plaisir à refaire un stage d'été :-)

Ce n'est pas à Samba de faire l'identification, ça fait doublon. Il peut
faire appel au système pour ça.

S'il en est capable, en effêt. Reste à trouver comment.

passdb backend : opendirectorysam
auth methods = opendirectory

sjnma

yep, mais le "passdb backend" est en trop.
Je ne veux pas à avoir à conserver les mots de passe localement.

Ok. Grâce à http://safari.oreilly.com, j'ai accès au bouquin de Bartosh.
Il y a en effêt quelques chapitres à lire.
Bon, je ferai ça demain.

Achète-le, ça vaut le coup. Dommage que Michael soit disparu si tôt, il
lui restait tant à nous faire partager :(

Bof, j'achète rarement le papier, je me contente d'une lecture écran.
safari.oreilly.com est interactif, au moins.
Un peu cher, toutes fois.

Evidement, il n'y a pas de serveradmin sur Mac OS X client :)

serveradmin est un outil en cli pour administrer Mac OS X Server, c'est la
version texte de l'application Server Admin.

Rien à voir avec le net join...

A mon avis il doit faire plus que de relancer samba.
A tester du moins.

Je ne distingue pas un TGT d'un autre ticket, on vois ça à quoi ?

Bah, en général il s'appelle krbtgt.

Alors oui, c'est ça.

Selon moi, c'est en ordre :
Kerberos n'est pas connu pour accepter une config foireuse :)

Oui, mais en même temps, si un client sans ticket n'arrive pas à
initialiser la procédure de demande de TGT pour obtenir ensuite un
Service Ticket, il y a un soucis quelque part. Pas dramatique, mais
dérangeant.

Euh, ... Non, c'est pas ce que je recherche : ça implique que la machine
soit configurée, ce qui n'est pas toujours le cas.

Et c'est discret dans le budjet, avec ça j'ai pas besoins de me
justifier sur la présence nouvelle de mac dans la salle serveurs.

Bah, un bel Xserve, ça le fait aussi et c'est autrement plus costaud,
quand même...

Oui, mais il faut le justifier dans un budjet. Quand mes serveurs seront
devenus totalement indispensable, je n'aurai pas de problème à obtennir
une config solide. Pour le moment je crée le besoins insinueusement :)

Tu arrives à le lire sans être root ?

C'est une question de principe.

Dans ce cas, ne fais pas confiance à Mac OS X, le hash (ssha-1) du mot
de passe de tous les utilisateurs est au même endroit.

ça c'est un cache.
L'original est sur le serveur.
Et si un utilisateur hack sa machine, il n'obtient que son propre mot de
passe plus le mot de passe admin local, ça vas pas l'avancer beaucoup.

Par contre si je dois descendre tous les mots de passe en local pour
permettre à n'importe qui de se loguer en smb, c'est autre chose.

Etre root, c'est histoire de 3 minutes si tu as un accès physique.

Mmmmmmmm, ça dépend de la sécurisation de la machine. Et puis, si tu as
un accès physique à tes serveurs, il y a plus grave.

Notre salle serveur est sous clef, évidement.
Mais j'ai assez souvent des utilisateurs qui font du file sharing.
Une habitude de quand le partage de fichier fonctionnait sur mac ;->

oui : security = ads
use spnego = yes
realm = ADS.EXAMPLE.COM
workgroup = ADS

plus le truc dans serveradmin, que je serais intéressé d'analyser.

Bah, c'est relancer Samba, en fait, tout simplement, pour que les
daemons voient le changement de configuration.

Je ne penses pas.

J'ai fait le test suivant :
install OSX client
bind ad dans DS
reboot
login avec un utilisateur de l'ad.
activation du windows file sharing
modif de smb.conf
(comenter "auth methods et passdb backend puis ajouter security, realm
et passer le workgroup en majuscules. J'ai mis le même nom que dans DS)
reboot

Et ça ne marche pas.

Puis j'ai fait un
net join -U admin -S serveur.ici.ch

Il fait le bind, j'ai dû touiller un peu, ça marche en krb comme en rpc.

Donc tu avais raison sur la non-nécessité d'avoir 2 comptes pour une
seule machine dans l'AD.
Par contre je pense quand-même que serveradmin fait un "net join" pour
modifier le compte de la machine et ajouter le service dans le keytab.

Sauf que bêtement, dans mon empressement j'ai pas comparé le keytab
avant et après le "net join". Ah là là.

Il doit y avoir un fallback sur du normal en-dehors de Kerberos,
normalement. Enfin, c'est comme ça avec Mac OS X Server, sauf à demander
uniquement Kerberos dans la configuration.

En effêt. Mais le fallback ne fonctionne que si le rpc est correct.
Dureste après un "net ads join" tu peux faire un "net rpc testjoin"

Voui. On voit surtout ta machine déclarée deux fois, une fois en tant
que 20014 et une autre fois en tant que c110. Effet du plugin DA et du
net join, je pense.

yep :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Ah bahhhhh, tu vois, Apple ne peut pas non plus toujours être en cause
;-)

Yep. Je commence à comprendre les rumeures de différents entre les dev
de samba et du reste de la comunauté :)
Ils ont vraiment fait cuisine à part.

Eh oui :-/

$ open /usr/share/swat/using_samba/toc.html

C'est livré :)

$ grep -ri opendirectory /usr/share/swat

mouarf, périmée ta doc ;)

Faudra en parler à M. O'Reilly :)

Viens nous voir, en 8 jours on te montre plein de trucs ;-)

Oui, évidement.
J'aurais plaisir à refaire un stage d'été :-)

Ben, le soucis c'est que ça vient de se finir...

passdb backend : opendirectorysam
auth methods = opendirectory

sjnma

yep, mais le "passdb backend" est en trop.
Je ne veux pas à avoir à conserver les mots de passe localement.

Yep. Il faut que je regarde ce qu'il met sur un Mac OS X Server qui
n'est que relié à un AD pour voir ce qui est utilisé.

Achète-le, ça vaut le coup. Dommage que Michael soit disparu si tôt, il
lui restait tant à nous faire partager :(

Bof, j'achète rarement le papier, je me contente d'une lecture écran.
safari.oreilly.com est interactif, au moins.
Un peu cher, toutes fois.

Mouais, j'ai eu une période d'essai Safari Online, c'est sympa de
pouvoir tout lire mais je préfère quand même le papier, ça permet de le
poser bien ouvert à côté et de tester tranquillement. Ca me permet aussi
de bouquiner dans le train.

serveradmin est un outil en cli pour administrer Mac OS X Server, c'est la
version texte de l'application Server Admin.

Rien à voir avec le net join...

A mon avis il doit faire plus que de relancer samba.

Dans la commande que tu as donné, non. Par contre, dans le début de la
procédure, il y a la phase ou il y a le "join kerberos" et là, ça fait
le boulot.

A tester du moins.

serveradmin stop windows et start windows, ça ne fait qu'arrêter et
démarrer le service windows, ça, j'en suis certain.

Bah, en général il s'appelle krbtgt.

Alors oui, c'est ça.

De toutes façons, tu n'as pas de ticket de services sans tgt.

Oui, mais en même temps, si un client sans ticket n'arrive pas à
initialiser la procédure de demande de TGT pour obtenir ensuite un
Service Ticket, il y a un soucis quelque part. Pas dramatique, mais
dérangeant.

Euh, ... Non, c'est pas ce que je recherche : ça implique que la machine
soit configurée, ce qui n'est pas toujours le cas.

Gné ?

Si une machine n'est pas configurée pour Kerberos, c'est normal que tu
n'obtiennes pas de ticket.

Bah, un bel Xserve, ça le fait aussi et c'est autrement plus costaud,
quand même...

Oui, mais il faut le justifier dans un budjet. Quand mes serveurs seront
devenus totalement indispensable, je n'aurai pas de problème à obtennir
une config solide. Pour le moment je crée le besoins insinueusement :)

Oh le vicieux :-D

Dans ce cas, ne fais pas confiance à Mac OS X, le hash (ssha-1) du mot
de passe de tous les utilisateurs est au même endroit.

ça c'est un cache.
L'original est sur le serveur.
Et si un utilisateur hack sa machine, il n'obtient que son propre mot de
passe plus le mot de passe admin local, ça vas pas l'avancer beaucoup.

Je te parle du hash du mdp d'un utilisateur Mac OS X, oui.
Effectivement, la recopie en local est une mauvaise idée.

Par contre si je dois descendre tous les mots de passe en local pour
permettre à n'importe qui de se loguer en smb, c'est autre chose.

Yep.

Mmmmmmmm, ça dépend de la sécurisation de la machine. Et puis, si tu as
un accès physique à tes serveurs, il y a plus grave.

Notre salle serveur est sous clef, évidement.
Mais j'ai assez souvent des utilisateurs qui font du file sharing.
Une habitude de quand le partage de fichier fonctionnait sur mac ;->

Et ?

Bah, c'est relancer Samba, en fait, tout simplement, pour que les
daemons voient le changement de configuration.

Je ne penses pas.

Si, serveradmin ne fait que relancer le service Windows. Par contre,
dans la procédure donnée en référence il y a d'autres phases qui font
plus.

J'ai fait le test suivant :
install OSX client
bind ad dans DS
reboot
login avec un utilisateur de l'ad.
activation du windows file sharing
modif de smb.conf
(comenter "auth methods et passdb backend puis ajouter security, realm
et passer le workgroup en majuscules. J'ai mis le même nom que dans DS)
reboot

Et ça ne marche pas.

Normal, pas de keytabs pour les services.

Puis j'ai fait un
net join -U admin -S serveur.ici.ch

Il fait le bind, j'ai dû touiller un peu, ça marche en krb comme en rpc.

Donc tu avais raison sur la non-nécessité d'avoir 2 comptes pour une
seule machine dans l'AD.

Ben oui, ça me paraissait illogique et un peu crade :)

Par contre je pense quand-même que serveradmin fait un "net join" pour
modifier le compte de la machine et ajouter le service dans le keytab.

Pas lui, enfin, pas cette étape-là. En 10.3 ce devait être fait par le
plugin AD quand on conectait un serveur. En 10.4, toujours sur un
serveur, il te demande d'aller cliquer sur un bouton à un endroit bien
précis, étape qui va créer les keytabs.

Sauf que bêtement, dans mon empressement j'ai pas comparé le keytab
avant et après le "net join". Ah là là.

:-)

Il doit y avoir un fallback sur du normal en-dehors de Kerberos,
normalement. Enfin, c'est comme ça avec Mac OS X Server, sauf à demander
uniquement Kerberos dans la configuration.

En effêt. Mais le fallback ne fonctionne que si le rpc est correct.
Dureste après un "net ads join" tu peux faire un "net rpc testjoin"

Et ?

Voui. On voit surtout ta machine déclarée deux fois, une fois en tant
que 20014 et une autre fois en tant que c110. Effet du plugin DA et du
net join, je pense.

yep :)

Et maintenant, tu n'as plus de doublons, si je suis bien ?

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Dans la commande que tu as donné, non. Par contre, dans le début de la
procédure, il y a la phase ou il y a le "join kerberos" et là, ça fait
le boulot.

Ah, ok.
J'aurais dû faire l'exercice complet pour m'en rendre compte.

Notre salle serveur est sous clef, évidement.
Mais j'ai assez souvent des utilisateurs qui font du file sharing.
Une habitude de quand le partage de fichier fonctionnait sur mac ;->

Et ?

Et je vais donc désormais tout configurer en smb, vu les ennuis qu'on a
en afp. ça au moins Apple aura du mal à le sacager, ça ne leur
appartient pas.

Il doit y avoir un fallback sur du normal en-dehors de Kerberos,
normalement. Enfin, c'est comme ça avec Mac OS X Server, sauf à demander
uniquement Kerberos dans la configuration.

En effêt. Mais le fallback ne fonctionne que si le rpc est correct.
Dureste après un "net ads join" tu peux faire un "net rpc testjoin"

Et ?

Et il dit que le rpc est ok. Donc le join ads fait également le join rpc
pour le cas où tu n'as pas de ticket krb.

Voui. On voit surtout ta machine déclarée deux fois, une fois en tant
que 20014 et une autre fois en tant que c110. Effet du plugin DA et du
net join, je pense.

yep :)

Et maintenant, tu n'as plus de doublons, si je suis bien ?

non, plus de doublons et un serveur smb qui fonctionne parfaitement sur
du Mac OS X client, intégré à un AD. Content, je suis :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas