Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
Plus que des gens qui font tourner du MS SFM :)
Est-ce que tu en utilises ?
-- Nicolas Michel
Nicolas-Michel_REMOVE
Jacques Perrocheau wrote:
Ici un Netapp configuré comment ? je ne sais pas, (authentification adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on lui envoie du cifs ou du smb.
Salut Jacques
On avait déjà discuté Netapp il me semble. A l'époque tu n'arrivais pas à mettre votre Netapp dans le domaine ldap. Est-ce que tu as pu améliorer les choses ? tu dis "adossé" et "se moque", qu'entends tu par là au juste ? Pas moyen de s'authentifier du tout ou ticket kerberos non accepté ?
-- Nicolas Michel
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Ici un Netapp configuré comment ? je ne sais pas, (authentification
adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on
lui envoie du cifs ou du smb.
Salut Jacques
On avait déjà discuté Netapp il me semble. A l'époque tu n'arrivais pas
à mettre votre Netapp dans le domaine ldap. Est-ce que tu as pu
améliorer les choses ? tu dis "adossé" et "se moque", qu'entends tu par
là au juste ? Pas moyen de s'authentifier du tout ou ticket kerberos
non accepté ?
Ici un Netapp configuré comment ? je ne sais pas, (authentification adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on lui envoie du cifs ou du smb.
Salut Jacques
On avait déjà discuté Netapp il me semble. A l'époque tu n'arrivais pas à mettre votre Netapp dans le domaine ldap. Est-ce que tu as pu améliorer les choses ? tu dis "adossé" et "se moque", qu'entends tu par là au juste ? Pas moyen de s'authentifier du tout ou ticket kerberos non accepté ?
-- Nicolas Michel
Nicolas-Michel_REMOVE
Laurent Pertois wrote:
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du service.
Ok, merci, c'est très intéressant.
Après quelques test, il s'avère que mon ticket SV.INTRANET.EPFL.CH n'est accepté que si je tapes cifs://serveur.epfl.ch/Share
donc smb ne veux toujours pas quoi que je tapes (enfin ça marche mais en me demandant un mot de passe) et cifs://serveur.sv.intranet.epfl.ch n'est pas accepté non-plus bien que le dns réponde.
Ce qui me confirme une fois de plus que je ne comprends rien aux DNS. Enfin je connais le principe de base, mais pas les implications dans des cas complexes avec divers dns-dhcp-domaines imbriqués.
Là où c'est dommage c'est que la navigation par la barre latérale du Finder appelle le nom bonjour.
un bref check de krb5.conf me raconte plein de choses sur [capaths], dns_lookup_kdc, dns_lookup_realm, dns_fallback, extra_addresses, ... Que je ne comprends pas.
Mais je me demande s'il n'y a pas moyen dans ton cas en étudiant un peu ces options de tuner un peu la config. La gui, après tout, ne ponds qu'une config très simple et épurée dans ce cas précis.
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte par lui-même, c'est moins important non ?
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé
mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du
service.
Ok, merci, c'est très intéressant.
Après quelques test, il s'avère que mon ticket SV.INTRANET.EPFL.CH n'est
accepté que si je tapes cifs://serveur.epfl.ch/Share
donc smb ne veux toujours pas quoi que je tapes (enfin ça marche mais en
me demandant un mot de passe) et cifs://serveur.sv.intranet.epfl.ch
n'est pas accepté non-plus bien que le dns réponde.
Ce qui me confirme une fois de plus que je ne comprends rien aux DNS.
Enfin je connais le principe de base, mais pas les implications dans des
cas complexes avec divers dns-dhcp-domaines imbriqués.
Là où c'est dommage c'est que la navigation par la barre latérale du
Finder appelle le nom bonjour.
un bref check de krb5.conf me raconte plein de choses sur [capaths],
dns_lookup_kdc, dns_lookup_realm, dns_fallback, extra_addresses, ...
Que je ne comprends pas.
Mais je me demande s'il n'y a pas moyen dans ton cas en étudiant un peu
ces options de tuner un peu la config. La gui, après tout, ne ponds
qu'une config très simple et épurée dans ce cas précis.
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand
on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte
par lui-même, c'est moins important non ?
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du service.
Ok, merci, c'est très intéressant.
Après quelques test, il s'avère que mon ticket SV.INTRANET.EPFL.CH n'est accepté que si je tapes cifs://serveur.epfl.ch/Share
donc smb ne veux toujours pas quoi que je tapes (enfin ça marche mais en me demandant un mot de passe) et cifs://serveur.sv.intranet.epfl.ch n'est pas accepté non-plus bien que le dns réponde.
Ce qui me confirme une fois de plus que je ne comprends rien aux DNS. Enfin je connais le principe de base, mais pas les implications dans des cas complexes avec divers dns-dhcp-domaines imbriqués.
Là où c'est dommage c'est que la navigation par la barre latérale du Finder appelle le nom bonjour.
un bref check de krb5.conf me raconte plein de choses sur [capaths], dns_lookup_kdc, dns_lookup_realm, dns_fallback, extra_addresses, ... Que je ne comprends pas.
Mais je me demande s'il n'y a pas moyen dans ton cas en étudiant un peu ces options de tuner un peu la config. La gui, après tout, ne ponds qu'une config très simple et épurée dans ce cas précis.
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte par lui-même, c'est moins important non ?
-- Nicolas Michel
laurent.pertois
Michel Nicolas Alex wrote:
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte par lui-même, c'est moins important non ?
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI, alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand
on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte
par lui-même, c'est moins important non ?
Ben, non, si je fais une MCX pour faire monter le volume
automatiquement, ça va passer, je vais utiliser la bonne URI, alors que
si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Bon, le gain n'est pas ennorme. Là où le sso est essentiel, c'est quand on veux que ça marche malgré l'utilisateur. Dès lors qu'il se connecte par lui-même, c'est moins important non ?
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI, alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-Michel_REMOVE
Laurent Pertois wrote:
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI,
Oui, c'est ce que je dis, tu ne passes pas par bonjour dans une mcx
alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
Des soucis dans le sens où ça lui demande son mot de passe ou dans le sens où il n'arrive pas à le rentrer ?
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI,
Oui, c'est ce que je dis, tu ne passes pas par bonjour dans une mcx
alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
Des soucis dans le sens où ça lui demande son mot de passe ou dans le sens où il n'arrive pas à le rentrer ?
-- Nicolas Michel
laurent.pertois
Michel Nicolas Alex wrote:
Laurent Pertois wrote:
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI,
Oui, c'est ce que je dis, tu ne passes pas par bonjour dans une mcx
Tu passes par ce que tu veux, en fait, mais là, tu vas y faire attention ;-)
alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
Des soucis dans le sens où ça lui demande son mot de passe ou dans le sens où il n'arrive pas à le rentrer ?
Dans le sens où il va devoir le rentrer, pas de sso, du coup.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Ben, non, si je fais une MCX pour faire monter le volume
automatiquement, ça va passer, je vais utiliser la bonne URI,
Oui, c'est ce que je dis, tu ne passes pas par bonjour dans une mcx
Tu passes par ce que tu veux, en fait, mais là, tu vas y faire attention
;-)
alors que
si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
Des soucis dans le sens où ça lui demande son mot de passe
ou dans le sens où il n'arrive pas à le rentrer ?
Dans le sens où il va devoir le rentrer, pas de sso, du coup.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ben, non, si je fais une MCX pour faire monter le volume automatiquement, ça va passer, je vais utiliser la bonne URI,
Oui, c'est ce que je dis, tu ne passes pas par bonjour dans une mcx
Tu passes par ce que tu veux, en fait, mais là, tu vas y faire attention ;-)
alors que si l'utilisateur se débrouille tout seul, il peut y avoir soucis.
Des soucis dans le sens où ça lui demande son mot de passe ou dans le sens où il n'arrive pas à le rentrer ?
Dans le sens où il va devoir le rentrer, pas de sso, du coup.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
kurtz_le_pirate
Jacques Perrocheau wrote:
In article <4850bf9b$0$12001$, "kurtz_le_pirate" wrote:
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ? Il me semble qu'il avait déjà été zappé ne restant que le support pour imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.) PAP Printer Access Protocol NBP Name Binding Protocol et ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x, c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS X 10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
c'est bien sûr du 2003 serveur avec sfm... et oui, cela existe encore. cela fonctionne avec tiger plus sous leopard.
mais j'ai trouvé une solution : il suffit de modifier le mode d'autentification du serveur macintosh en "apple crypté ou microsoft".
en tout cas, je suis bien d'accord. tout ceci reste de la bidouille. je crois que je vais explorer sérieusement extremez-ip....
-- klp "bug : probleme d'interface entre la chaise et le clavier"
Jacques Perrocheau wrote:
In article <4850bf9b$0$12001$426a34cc@news.free.fr>,
"kurtz_le_pirate" <kurtzlepirate@yahoo.fr> wrote:
toujours suite au passage de tiger à leopard (10.5.2), il
est impossible au utilisateurs de se connecter en 'afp' sur
le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela
fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ?
Il me semble qu'il avait déjà été zappé ne restant que le support pour
imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.)
PAP Printer Access Protocol
NBP Name Binding Protocol
et
ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut
vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x,
c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS
X
10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont
pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K
server... !
c'est bien sûr du 2003 serveur avec sfm... et oui, cela existe encore.
cela fonctionne avec tiger plus sous leopard.
mais j'ai trouvé une solution : il suffit de modifier le mode
d'autentification du serveur macintosh en "apple crypté ou microsoft".
en tout cas, je suis bien d'accord. tout ceci reste de la bidouille. je
crois que je vais explorer sérieusement extremez-ip....
--
klp
"bug : probleme d'interface entre la chaise et le clavier"
In article <4850bf9b$0$12001$, "kurtz_le_pirate" wrote:
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ? Il me semble qu'il avait déjà été zappé ne restant que le support pour imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.) PAP Printer Access Protocol NBP Name Binding Protocol et ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x, c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS X 10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
c'est bien sûr du 2003 serveur avec sfm... et oui, cela existe encore. cela fonctionne avec tiger plus sous leopard.
mais j'ai trouvé une solution : il suffit de modifier le mode d'autentification du serveur macintosh en "apple crypté ou microsoft".
en tout cas, je suis bien d'accord. tout ceci reste de la bidouille. je crois que je vais explorer sérieusement extremez-ip....
-- klp "bug : probleme d'interface entre la chaise et le clavier"
Jacques Perrocheau
In article <1iigvsr.147wvy4rbc3y8N%, (Michel Nicolas Alex) wrote:
On avait déjà discuté Netapp il me semble.
Oui.
A l'époque tu n'arrivais pas à mettre votre Netapp dans le domaine ldap.
Ce n'est pas moi qui gère ce serveur.
Est-ce que tu as pu améliorer les choses ?
Non, il ne se sont pas décidés à le mettre sous Active Directory, ce qui d'après le constructeur est la seule façon pour faire passer les mots de passe en crypté.
tu dis "adossé" et "se moque", qu'entends tu par là au juste ?
Il est indifférent à la commande cifs:// ou smb://. Bien que doctement, le responsable ait essayé de m'expliquer que ce n'était pas "pareil".
Pas moyen de s'authentifier du tout ou ticket kerberos non accepté ?
Pas question de ticket Kerberos ici, on envoie login et mot de passe en clair ;-(.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article
<1iigvsr.147wvy4rbc3y8N%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
On avait déjà discuté Netapp il me semble.
Oui.
A l'époque tu n'arrivais pas à mettre votre Netapp dans le domaine
ldap.
Ce n'est pas moi qui gère ce serveur.
Est-ce que tu as pu améliorer les choses ?
Non, il ne se sont pas décidés à le mettre sous Active Directory, ce qui
d'après le constructeur est la seule façon pour faire passer les mots de
passe en crypté.
tu dis "adossé" et "se moque", qu'entends tu par là au juste ?
Il est indifférent à la commande cifs:// ou smb://. Bien que doctement,
le responsable ait essayé de m'expliquer que ce n'était pas "pareil".
Pas moyen de s'authentifier du tout ou ticket kerberos non accepté ?
Pas question de ticket Kerberos ici, on envoie login et mot de passe en
clair ;-(.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1iigvsr.147wvy4rbc3y8N%, (Michel Nicolas Alex) wrote:
On avait déjà discuté Netapp il me semble.
Oui.
A l'époque tu n'arrivais pas à mettre votre Netapp dans le domaine ldap.
Ce n'est pas moi qui gère ce serveur.
Est-ce que tu as pu améliorer les choses ?
Non, il ne se sont pas décidés à le mettre sous Active Directory, ce qui d'après le constructeur est la seule façon pour faire passer les mots de passe en crypté.
tu dis "adossé" et "se moque", qu'entends tu par là au juste ?
Il est indifférent à la commande cifs:// ou smb://. Bien que doctement, le responsable ait essayé de m'expliquer que ce n'était pas "pareil".
Pas moyen de s'authentifier du tout ou ticket kerberos non accepté ?
Pas question de ticket Kerberos ici, on envoie login et mot de passe en clair ;-(.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
