Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: alcasar-conup.sh et Filter-ID récupéré depuis annuaire EOLE (SCRIBE) [ Répondre ] Par : Richard REY (Rexy) on 2017-03-18 13:10 | [forum:485782] |
|
Bonjour, Concernant l'attribut Filter_ID, ne serait-il pas plus simple de ne pas le demander lors de la requête LDAP ? |
|
| RE: alcasar-conup.sh et Filter-ID récupéré depuis annuaire EOLE (SCRIBE) [ Répondre ] Par : Nicolas BAUDRAND on 2017-03-13 14:41 | [forum:485758] |
|
Désolé pour le retard, je ne recevais pas les mails du Forum... Bref, en ce qui concerne Eleve et eleve, c'est une histoire de casse. Moi ce que je souhaite, c'est empêcher les comptes génériques en provenance du ldap de pouvoir accèder à Internet à travers Alcasar. Comme le filtrage ldap ne fonctionne pas comme je le souhaite (&(!uid=eleve)(!uid=prof)...), je passe donc par la création d'un compte du même nom sur Alcasar. Sauf que l'authentification ldap n'est pas sensible à la casse et que alcasar lui si. Ca veut dire qu'une saisie "eleve" authentifié par ldap matchera bien sur "eleve" de alcasar et donc héritera de toutes les restrictions souhaitées mais que "Eleve" lui aussi authentifié par ldap ne matchera pas "eleve" de alcasar et tombera donc sur les droits du groupe "ldap". |
|
| RE: alcasar-conup.sh et Filter-ID récupéré depuis annuaire EOLE (SCRIBE) [ Répondre ] Par : Franck BOUIJOUX on 2017-02-08 08:22 | [forum:485568] |
|
Bonjour, bien vu et c'est un des points sur lesquels on doit bosser cette année. En partant du principe que l'on peut donner le code que l'on veut afin qu'il soit associé au bon profil de filtrage, il suffirait donc de donner le bon code à chaque utilisateur. Ma question, est-ce que si cet attribut est rempli au nom du groupe dans lequel se trouve des utilisateurs celui-ci est également retourné à radius ? Par contre, je n'ai pas pigé votre dernier point sur le Eleve et eleve. |
|
| alcasar-conup.sh et Filter-ID récupéré depuis annuaire EOLE (SCRIBE) [ Répondre ] Par : Nicolas BAUDRAND on 2017-02-01 17:23 | [forum:485556] |
|
Bonjour, Nous avons remarqué que l'ors d'une authentification ldap, alcasar tentait aussi de récupérer des attributs radius dont "radiusFilterId" qui se retrouvé mappé en "Filter-Id" puis transmis à coova-chilli et enfin à "/usr/local/bin/alcasar-conup.sh" Notre soucis est que l'annuaire ldap est celui de la suite Eole (scribe) qui fourni un attribut radiusFilterId générique "Enterasys:version=1:policy=Enterprise User" et qui match tous nos users ldap en not_filtered Dans la prochaine version, il serait bon de ne faire correspondre que "00000000" en "not_filtered" et "*" en havp_bl. ipset del not_auth_yet $FRAMED_IP_ADDRESS # Add user to the SET (function of his filtering level) case $FILTER_ID in # NOT_FILTERED "00000000") set="not_filtered" ;; # HAVP "00000001") set="havp" ;; # HAVP + Blacklist "00000011") set="havp_bl" ;; # HAVP + Whitelist "00000101") set="havp_wl" ;; # Everything else *) set="havp_bl" ;; esac ipset add $set $FRAMED_IP_ADDRESS Second point : Si je veux empecher mes uid génériques "eleve" et "prof" d'accèdere à Alcasar, je ne peux le faire depuis le base_filter, il me faut modifier le module ldap de radius Troisième point et je pense le pire. Pour associer un profil particulier à un compte provenant de ldap, il suffit de créer un compte local du même nom. OK mais un petit malin qui écrit "Eleve" au lieu de "eleve" passe outre la restriction du compte crée manuellement. |
|
