[smb] net join et le plugin AD

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

Puis j'ai passé la commande de join :
# net join -w MON_DOMAIN -U totoadmin

Je peux me tromper, je n'ai jamais beaucoup utilisé cette commande (sauf
une fois quand je cherchais un truc) vu que je joins plutôt des Mac OS X
Server que des clients à des domaines AD et que dans ce cas, il y a un
outil dédié. Mais ta commande ne devrait-elle pas plutôt ressembler à un
truc comme ça (je la fais bavarde) :

# net join ADS MEMBER -U totoadmin -w MON_DOMAIN

De plus, je n'ai pas le souvenir que cette commande soit suffisante côté
kerberos, elle ne doit pas créer le principal pour le service sur le
serveur ni ramener la keytab.

--
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:

Puis j'ai passé la commande de join :
# net join -w MON_DOMAIN -U totoadmin

Je peux me tromper, je n'ai jamais beaucoup utilisé cette commande (sauf
une fois quand je cherchais un truc) vu que je joins plutôt des Mac OS X
Server que des clients à des domaines AD et que dans ce cas, il y a un
outil dédié. Mais ta commande ne devrait-elle pas plutôt ressembler à un
truc comme ça (je la fais bavarde) :

# net join ADS MEMBER -U totoadmin -w MON_DOMAIN

Oui, peut-être.
En principes "net join -U totoadmin" suffit.
(C'est ce que j'ai mis sur mes autres serveurs, lesquels fonctionnent)

Bon, là je viens de tester :
net ads join "Computers/Servers" -S dc.ici.ch -U nmicheladm
-w MON_DOMAIN

Il me réponds :
ads_add_machine_acct: Host account for archives-mac01 already exists -
modifying old account
Using short domain name -- MON_DOMAIN

Donc ça voudrait dire que les bind ads et rpc sont fait.
Résultat, le kerberos (ads) fonctionne, le rpc bloque.
Il n'y a même pas de log sur le serveur d'authentification, donc le lien
ne marche probablement pas.

Bon, il y a cette commande, net rpc vampire, que je vais tester...
Pour voir.

De plus, je n'ai pas le souvenir que cette commande soit suffisante côté
kerberos, elle ne doit pas créer le principal pour le service sur le
serveur ni ramener la keytab.

C'est juste mais le kerberos est très bien réglé par le plugin du
Directory Services, tout est généré automatiquement et ça fonctionne
bien. C'est en rpc que j'ai des problèmes...

Merci Laurent :)

--
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:

De plus, je n'ai pas le souvenir que cette commande soit suffisante côté
kerberos, elle ne doit pas créer le principal pour le service sur le
serveur ni ramener la keytab.

C'est juste mais le kerberos est très bien réglé par le plugin du
Directory Services, tout est généré automatiquement et ça fonctionne
bien. C'est en rpc que j'ai des problèmes...

Mmm, le plugin configure le fichier permettant de s'intégrer dans le
royaume Kerberos, mais il n'intègre aucuns services kerbérisés dans le
royaume.

Merci Laurent :)

De rien.

--
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:

Mmm, le plugin configure le fichier permettant de s'intégrer dans le
royaume Kerberos, mais il n'intègre aucuns services kerbérisés dans le
royaume.

Oui, c'est aussi ce que je pensais.
Pourtant ça marche :)
--
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:

Mmm, le plugin configure le fichier permettant de s'intégrer dans le
royaume Kerberos, mais il n'intègre aucuns services kerbérisés dans le
royaume.

Oui, c'est aussi ce que je pensais.
Pourtant ça marche :)

Il doit y avoir autre chose, c'est étrange. Cela dit, je ne me suis
jamais trop penché sur la question en dehors de l'intégration d'un Mac
OS X Server dans un royaume créé par un AD.

Cela dit, je n'ai pas non plus fouillé pour savoir ce que fait
exactement la commande net join... Peut-être fait-elle ce qui est
nécessaire pour la partie kerberos.

Cela dit, si je me souviens bien, également, la commande net join est
optionnelle, le plugin AD de Directory Services doit déjà ajouter la
machine dans l' AD...

--
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:

Cela dit, si je me souviens bien, également, la commande net join est
optionnelle, le plugin AD de Directory Services doit déjà ajouter la
machine dans l' AD...

Ce qu'il y a sur OSX client c'est que si tu actives bêtement le partage
smb, même en ayant fait le bind sur l'AD avec le plugin, samba ne peux
authentifier que les utilisateurs locaux ayant un passwd dans la base
locale.

Donc à moins de répliquer tous les utilisateurs en local, pas moyen de
faire un petit serveur samba.

Par contre, avec security = ads il délègue la sécurité à l'AD, tout
comme devrait le faire opendirectory.

Faut dire que samba est un système paralèle, avec son dc, son winbind
sous linux, bref ils ont refait plein de chose à leur sauce.

Bon, je vais réinstaller ce serveur from scratch, ça finira bien par
aller :)
--
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:

Ce qu'il y a sur OSX client c'est que si tu actives bêtement le partage
smb, même en ayant fait le bind sur l'AD avec le plugin, samba ne peux
authentifier que les utilisateurs locaux ayant un passwd dans la base
locale.

Vivi, j'avions oublié que ça ne modifiait pas le smb.conf.

Donc à moins de répliquer tous les utilisateurs en local, pas moyen de
faire un petit serveur samba.

Bah vi...

Par contre, avec security = ads il délègue la sécurité à l'AD, tout
comme devrait le faire opendirectory.

Yep. Mais je ne suis toujours pas certain que le net join ne fasse pas
double emploi. Par contre, ça ne doit pas faire du kerberos si tu ne
transfères pas les keytabs créées sur l'AD. Ca doit plutôt utiliser le
classique login/password.

Faut dire que samba est un système paralèle, avec son dc, son winbind
sous linux, bref ils ont refait plein de chose à leur sauce.

Tout refait, mais ils n'avait guère le choix. D'un autre côté, les
Directory Services de Mac OS X font bien des choses que Samba a du
réimplémenter car ça n'existe pas sur d'autres OS, comme la connexion à
l'AD, par exemple.

Bon, je vais réinstaller ce serveur from scratch, ça finira bien par
aller :)

Ok :)

--
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:

Par contre, avec security = ads il délègue la sécurité à l'AD, tout
comme devrait le faire opendirectory.

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

Tu veux dire, par rapport à Open Directory ?
Faudrait voir comment s'y prends Mac OS X serveur pour que samba aille
s'authentifier sur l'AD via le plugin directory access, s'il le fait.

En tout cas sur Mac OS X client, de base ça ne passe pas et c'est
dommage. J'en vien même à regretter pam et winbind, pour dire :)

Par contre, ça ne doit pas faire du kerberos si tu ne
transfères pas les keytabs créées sur l'AD. Ca doit plutôt utiliser le
classique login/password.

Bon, ça tourne. Voici la procédure :

1) faire le bind sur l'AD avec le plugin Directory Services.
2) modifier smb.conf comme suit (je ne liste que les modifs):
[global]
; auth methods = guest opendirectory
; passdb backend = opendirectorysam guest
security = ADS
realm = MON.DOMAINE.COM
password server = 192.42.198.12
server string = le-hostname
; client ntlmv2 auth = no
client ntlmv2 auth = yes
client plaintext auth = no
netbios name = le-hostname
preferred master = No
local master = No
domain master = No
wins server = 192.42.198.12

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.

A noter encore que le netbios name ne peut pas, sauf erreur, être le
même que le nom mis dans le plugin du Directory Srevices, sinon ça entre
en conflict.

3) se loguer en tant qu'utilisateur de l'AD pour avoir un ticket
kerberos puis faire le bind de samba comme suit :

net join -U administrator -S 192.42.198.12

On peut ensuite contrôler le bind avec des commandes tel que :
net rpc testjoin
net ads testjoin
net -U administrator -S 192.42.198.12 rpc user
net -U administrator -S 192.42.198.12 ads user

Bon, je vais réinstaller ce serveur from scratch, ça finira bien par
aller :)

Ok :)

Bon, ça tourne à présent.
Finalement le problème était je crois qu'il vaut mieux spécifier le
password server = IP et de mettre "-S 192.42.198.12" dans les commandes
sinon "net" part aux fraises.

Merci Laurent :)
--
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:

Par contre, avec security = ads il délègue la sécurité à l'AD, tout
comme devrait le faire opendirectory.

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.

Faudrait voir comment s'y prends Mac OS X serveur pour que samba aille
s'authentifier sur l'AD via le plugin directory access, s'il le fait.

Non, net join, sjmsb, inscrit la machine dans l'AD, comme il faut le
faire pour toutes les machines. Comme en plus tu ne l'inscris que comme
membre, ça fait double emploi, Directory Access fait déjà ça.

En tout cas sur Mac OS X client, de base ça ne passe pas et c'est
dommage. J'en vien même à regretter pam et winbind, pour dire :)

Qu'est-ce qui ne passe pas ?

La machine est inscrite et peut donc consulter plus complètement l'AD.
Par contre, sur un client, les services ne sont pas reconfigurés pour
gérer une authentification kerberos, par exemple, surtout samba, mais
c'est normal, ce n'est pas l'utilisation par défaut de Mac OS X, c'est
prévu, et configuré, dans Mac OS X Server.

Par contre, ça ne doit pas faire du kerberos si tu ne
transfères pas les keytabs créées sur l'AD. Ca doit plutôt utiliser le
classique login/password.

Bon, ça tourne. Voici la procédure :

Ok...

1) faire le bind sur l'AD avec le plugin Directory Services.

Voui, inscription de la machine dans l'AD, nécessaire à la suite.

2) modifier smb.conf comme suit (je ne liste que les modifs):
[global]
; auth methods = guest opendirectory
; passdb backend = opendirectorysam guest
security = ADS
realm = MON.DOMAINE.COM
password server = 192.42.198.12
server string = le-hostname
; client ntlmv2 auth = no
client ntlmv2 auth = yes
client plaintext auth = no
netbios name = le-hostname
preferred master = No
local master = No
domain master = No
wins server = 192.42.198.12

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.

A noter encore que le netbios name ne peut pas, sauf erreur, être le
même que le nom mis dans le plugin du Directory Srevices, sinon ça entre
en conflict.

Ca fait une double déclaration, le plugin Directory Access a déjà fait
ce que tu souhaites faire après...

3) se loguer en tant qu'utilisateur de l'AD pour avoir un ticket
kerberos puis faire le bind de samba comme suit :

net join -U administrator -S 192.42.198.12

Tu fais un join, ça a déjà été fait à l'étape 1.

On peut ensuite contrôler le bind avec des commandes tel que :
net rpc testjoin
net ads testjoin
net -U administrator -S 192.42.198.12 rpc user
net -U administrator -S 192.42.198.12 ads user

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

Bon, je vais réinstaller ce serveur from scratch, ça finira bien par
aller :)

Ok :)

Bon, ça tourne à présent.
Finalement le problème était je crois qu'il vaut mieux spécifier le
password server = IP et de mettre "-S 192.42.198.12" dans les commandes
sinon "net" part aux fraises.

Merci Laurent :)

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 ?

--
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)

- 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.

Au final, il faut donc un double bind, l'un pour samba et un pour OD.
C'est sale, mais fonctionnel.
Apparement tu ne trouves pas la soupe à ton goût :)

[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.

[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 ...
Vu que par défaut avec "security = user" ça ne marche pas.


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.
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 :)

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.
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.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas