Active Directory - SASL - svnserve

Red Hat, Fedora, CentOS

Sziasztok,

Az a feladatom hogy összekössem az Active Directory szerverünket az svn-nel. Apache-os megoldás nemjó mert svn:// protokoll kell.
Az alábbi leírás követése után ugyanabba a hibába futottam mint a bejegyzés írója ( http://serverfault.com/questions/367037/svn-sasl-commit-authorisation-f… )

miszerint a testsaslauthd sikeresen authentikál de az SVN nem.

Hiába készítettem el a /usr/lib/sasl2/svn.conf file-t.
Át is linkeltem a /etc/sasl2-be és a /usr/lib64/sasl2 könyvtárba is.

Próbáltam a /etc/sysconfig/saslauthd -be is beleírni a /usr/lib/sasl2/svn.conf -fájlba beleírandókat , hátha. De nem.
Ráteszteltem DIGEST-MD5 tel is. nem segített

snvserve logja meg pusztán enniyt ír amikor próbálnék feljelentkezni

- ERR - 0 210002 Network connection closed unexpectedly

Van egy olyan érzésem hogy az svn-t tökre nem érdekli mi van az svn.conf-ban... :-(

SELinux kikapcsolva rajta

Van valakinek ötlete hogy merre kellene elindulnom a hibakeresésben?

Rendszer
---------
Centos 6.3
svn 1.7.7 - with Cyrus SASL

  • 14719 megtekintés

( Zsugabubus | 2013. 03. 29., p – 20:29 )

És a "testsaslauthd -u .... -p ... -s svn" működik?
A bejegyzés írójának nem az volt a baja, hogy nem authentikál, hanem hogy read-only volt a szerver (azaz authentikált, csak nem authorizált).

Hello,

Csak az első sorokat néztem.

alapból a /usr/lib/x86 alatt kereste a libeket és arra jött a válasz hogy nincs meg a file.
De ahogy utána néztem ha az usr/lib/x86 alatt nem találja akkor nézi tovább a
/usr/lib/sasl2 és /usr/lib -ben. Tehát megtalálta.

Amugy probléma viszont azzal volt egyrászt hogy az svn.conf egy linkelt file volt.
Az elején nem tudtam hogy konkrétanhonnan keresi a .conf file-t ezért a /usr/lib/sasl2/svn.conf -ot átlinkeltem a /usr/lib64/sasl2/svn.conf névre.

Namost miután az strace visszaadta a logot abból kiderült hogy az svn.conf nem lehet linkelt ezért áttettem a /usr/lib64/sasl2 alá és így már látta

WANDisco csomag. A WANDsico yum repóbol.

( hrgy84 | 2013. 04. 02., k – 15:37 )

Lecci, ha meglesz a megoldas, ird be, hogy mi volt az, engem felettebb erdekelne.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Félig működik.

Win. Tortoise 1.7.10 : működik
Win. Eclipse Subvesive: működik
Win .SlikSVN cli : nem működik de gondolom valami ~appdata/Subversion/servers beállítás lesz a hunyó

Linux SVN cli: működik

A konfigok:

/etc/default/saslauths.conf

ldap_servers: ldap://x.x.x.x
ldap_default_domain: ertelemszeruen - domain.com
ldap_search_base: ertelemszeruen - DC=domain, DC=com

ldap_bind_dn: ertelemszeruen
ldap_bind_pw: ertelemszeru

ldap_deref: never
ldap_restart: yes
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%U
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 30

/usr/lib64/sasl2/svn.conf

ldapdb_mech: PLAIN
auxprop_plugin: ldap
pwcheck_method: saslauthd
mech_list: PLAIN

Az svnserve nem olvasta fel rendesen a konfig file-t, kézzel kellett hozzáadni

#svnserve -d -r repository --log-file /var/log/svn/svnlog.log --config-file /home/svn/repository/conf/svnserve.conf

igen. Az használja de kifelejtettem még egy konfig file-t. Nekem csak ugy megy ha ez is be van állítva.
Megadja az SASL socket-et és az saslauthd.conf meghívásával konfigurálja az sasld-t.

Fura, mert ha az /etc/default/saslauthd.conf tartalmát próbáltam direktbe beletenni akkor kiirta hogy nem okés.
Gonodolom soronként hívja meg, ezért kell a másik conf.

/etc/sysconfig/saslauthd

SOCKETDIR=/var/run/saslauthd
MECH="ldap"
FLAGS="-O /etc/default/saslauthd.conf"
START="yes"

Amúgy ez tényleg működik normálisan AD-vel? Merthogy userPassword alapján az sose fog azonosítani, mert azt az AD-ból nem lehet kiolvasni, ez a felállás max. mindig azzal a userrel megy, akit beírtál az ldap_bind_dn-be, a belekódolt jelszóval.
Vagy nem azt akarod, hogy az svn-nek beadod az AD-s userneved/jelszavad, és vagy beenged, vagy nem?

Na ja, de a saslauthd ebben az esetben kiolvasná a userPasswordot, és azt hasonlítja össze azzal, amit te küldesz neki. Azért kíváncsi lennék, hogy teljesen fals jelszóval az svn részéről nem enged-e be így :)
Vagy akár a testsaslauthd -u .. -p rossz_jelszó nem "OK"-kal végződik...

Sziasztok,

Rendesem belém húztátok az aggodalmat ezekkel a kérdésekkel ezért nekiálltam és teszteltem.

1.
saslauthd -u... -p rossz jelszó -- authentication failed

2.
tortoiseSVN usernév + rossz jelszó -- failed

3.
TortoiseSVN usernév + AD jelszó -- failed

A tortoiseSVN esetében nem a bind-hez használt user/jelszó párost használtam.

Ez nem AD specialitas, errol beszeltem en is.

Itt nem READ tortenik, hanem AUTH - ami egy tok mas muvelet, es az userPassword attributum alapbol AUTH-olhato mindenki szamara. OpenLDAP-ban peldaul meg anonymok is AUTH-olhatnak hozza by default.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez valóban így van, bind requestnél, de ha eleve bind-del az AD, hez, akkor minek a beégetett ldap_bind_dn és ldap_bind_pw? Csak azért érdekel, mert kíváncsiságból kipróbáltam nálam is a fenti saslauthd.conf-al, és érdekes dolgokat művel - szóval nem működik :)
De ha nálad jó, akkor nem is feszegetem tovább. (Amúgy AD-ben nem is userPasswordnek hívják azt az attributumot, én szerintem ha kivennéd a konfigból, akkor is ugyanúgy működne tovább, azt, hogy összehasonlítja a jelszóval, a saslauthd forráskódjából néztem ki, minden esetre érdekes).

Azert, mert valoszinuleg, mielott bindelne hozza, lekerdezi, hogy letezik-e a user. Vagy pl. tamogatna extra semakat is, amivel lehetne plusz hozzaferest szabalyozni, pl. hogy le van-e tiltva a user, meg ilyesmi. Nem tudom, ezzel csak azt akarom mondani, hogy van ertelme, mert az auth egyszerre hasznos es kevesse hasznos info, jo esellyel szukseges lehet a kiegeszitese.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Na szóval nem hagyott nyugodni a dolog, úgyhogy kidebuggoltam :)
Szóval a fenti esetben:
- A saslauthd az ldap_bind_dn userrel, és ldap_bind_passworddel binddel (de szép szó).
- A search filterben meghatározott kereséssel megkeresi az adott objektumot, a fenti filterrel ez a user objektum lesz
- A megtalált objektum DN-jét kéri le (azaz nem a userPasswordot - ezt csak ldap_auth_method: customnál használná!)
- A lekérdezésben visszakapott DN és az "igazi" jelszóval binddel újra, ha ez sikeres, akkor OK, ha nem, akkor NO

Egy lépcsőssé lenne tehető a dolog az ldap_use_sasl: yes használatával (ugye a fenti két lépcsős dolog azért kell, hogy egy sima usernévből DN-t lehessen csinálni, lévén a simple bind az DN-nel működik csak).

Nem, a simple bind használ DN-t (azért is van ez a dupla bejelentkezés), a sasl auth az valamilyen auth id-t, AD esetében a sima usernevet leginkább. De PLAIN mech-hel nem nagyon megy az AD, csak DIGEST-MD5-tel sikerült nekem eddig működésre bírnom, viszont annak a DIGEST-MD5-ben levő különböző mezők miatt muszáj, hogy a DNS forward és rev zónái teljesen hibátlanul legyenek beállítva.

Igazad volt.
Kiszedtem az userPassword-ot es az saslauthd ugyanúgy jól működik

Azért kell a két lépcső mert az SVN-be belépéshez az SAMAccountName mezőnek megfelelő formátumot használnak az userek.

DE hogy a SlikSVN miért nem authentikál az még mindig rejtély számomra.

Az authentikáció meg szörnyen lassú lett

Nekem mar a testsaslauthd sem mukodik. tshark szerint nincs forgalom a dc fele, strace szerint meg sztem meg sem nyitja a config filet:

execve("/usr/local/sbin/saslauthd", ["/usr/local/sbin/saslauthd", "-a", "ldap", "-d", "-c", "-O", "/etc/saslauthd.conf", "-m", "/var/run/saslauthd/"], [/* 25 vars */]) = 0
write(2, "saslauthd[7398] :main "..., 68saslauthd[7398] :main : mech_option: /etc/saslauthd.conf

Ja, ez mar sajat forditas, de a gyari ugyanez.
CentOS 6.4
Mindjart ideiorm a configot.

--
http://www.micros~1


root@centos etc]# cat /etc/saslauthd.conf
###################################################################

ldap_servers: dc01.local

ldap_default_domain: local

ldap_search_base : "OU=users,DC=local"

ldap_bind_dn: "CN=celtic-admin,OU=it,OU=users,DC=local"

ldap_bind_pw: *****

# Misc options for LDAP to make it work with Microsoft AD. Nothing to change here, move along…
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: yes
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 30
ldap_cache_ttl: 30
ldap_cache_mem: 32768

#########################################################################
[root@centos etc]#

a binddn es hasonlok jok, csak kivettem belole a ceges infokat


[root@centos etc]# cat /usr/lib64/sasl2/svn.conf
ldapdb_mech: PLAIN LOGIN
#auxprop_plugin: ldapdb
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

[root@centos etc]#

Itt fentebb probalkoztam
ldap_mech/ldapdb_mech es auxprop_plugin: ldapdb / auxprop_plugin: ldap verziokkal is, de semmi

A server:
saslauthd -a ldap -d -c -O /etc/saslauthd.conf -m /var/run/saslauthd/

A kapcsolodas:
testsaslauthd -u celtic-admin’ -p ***** -s svn

AAAAAAAAAAAAAAAAAAAAAAAAA
Mar nem eloszor viccel igy meg a centos, a lathatatlan aposztroffal :((((
Amig nem masolom, nem latszik, csak a masolatban

--
http://www.micros~1

( Celtic v | 2013. 11. 27., sze – 14:00 )

Valakinek barmi otlet, miert nem olvassa be a sasl az /etc/saslauthd.conf filet?
Mint emlitettem:
1 .konzol1
saslauthd -a ldap -d -m /var/run/saslauthd -O /etc/saslauthd.conf
2. konzol2
/usr/sbin/testsaslauthd -u celtic-admin -p ****

Rogton nyomja a NO-t. EZ nem is zavarna, az zavar, hoyg strace futtatva a saslauthd proggit nem laccik, hoyg megnyitna a ldap config filet (nem az, hogy nem erti az ott levot vagy barmi hasonlo, egyszeruen nem olvassa be)

Mi lehet az oka? Barmi otlet? (Ha torlom a filet, az se zavarja). Ez a gyari centos6-ban levo de ugyanez, ha leforditom a legutolso forrasbol.

Jaigen, otthoni Debianon (testing) is ez van. Egyszeruen nem ertem, mit cseszek el.

[root@centos ~]# rpm -qa | grep sasl
cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-devel-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-sql-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-ntlm-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-ldap-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64
[root@centos ~]#

Parancssorbol adom meg az auth mechet is (ldap), direkt kihangsulyozom a config file helyet - es semmi.

Otlet?

--
http://www.micros~1

Vagy en ertem felre, vagy itt kellene lennie az LDAP-nak is.....
[root@centos ~]# sasl2-shared-mechlist
Available mechanisms: PLAIN,ANONYMOUS,LOGIN,CRAM-MD5,GSSAPI,NTLM,DIGEST-MD5
Library supports: EXTERNAL,DIGEST-MD5,NTLM,GSSAPI,CRAM-MD5,LOGIN,ANONYMOUS,PLAIN

Az a baj, hogy pl. postfixben is pam-mysql az sql support, tehat nem tudom megnezni, miket tolt be.

--
http://www.micros~1

tsharkot probaltam. Az ossz forgalom a DC fele DNS keres (es valasz) volt. Tehat van koztuk kapcsolat. Eppen csak dns-en kivul mas forgalom nincs. (Ahoyg feljebb irtam, strace-bol nekem ugy tunik, magat a config filet sem olvassa be, ha letorlom, akkor sem reklamal)

Feladtam, megprobalom gssapi iranybol.

(Es mire kesz lesz, at is allunk git-re, legalabbis a fejlesztok pedzegetik...)

--
http://www.micros~1

( Celtic v | 2013. 12. 04., sze – 16:23 )

Tovabbszenvedtem. Van egy ilyen:
http://darkdragonthoughts.blogspot.hu/2011/03/setting-up-svnserve-on-ce…

Vagyis Kerberos legyen, probaljuk.

Probalom elinditani:
saslauthd -a kerberos5 -d -V

Es dob egy hatast, nem tud elindulni. Megneztem strace-szel es mit latok: BEOLVASSA az /etc/saslauthd.conf filet....
Ahogy toroltem, elindult.

Ebben ez az igazan izgalmas (man saslauthd)

FILES
/var/run/saslauthd/mux The default communications socket.

/etc/saslauthd.conf The default configuration file for ldap support.

Szoval vagy en nem ertek valamit, vagy a demonok jatszanak velem, de elvileg a fenti filet csak akkor kellene olvasnia, ha "-a ldap" az inditasa. Akkor persze nem olvassa, ezt mar fentebb irtam.

--
http://www.micros~1