Kommende LDAP-endringer - flere klienter ber?res

• Oversikt
• Detaljer

Oversikt

N? kommer noen puljer med LDAP-endringer som vil knekke noen klienter. Det gjelder ldap.uio.no, ikke Active Directory (Windows sin LDAP).

Si ifra hvis noen trenger unntak: katalog-drift@usit.uio.no, eller "ldap" under uio-it (Mattermost).  Det blir nok noen runder med "reverser endringer, fiks klienter, pr?v igjen".

Kan testes mot ldaps://ldap-test.uio.no.  Oppgi tidspunkt og IP-adresse hvis dere sp?r hva ldap-loggen sier klienten gjorde.

Hver pulje vil varsles.

Onsdag 10. januar (ferdig):

• Ryddet i IP-ACLer og b?r ikke merkes.

Mandag 22. januar (ferdig):

• Brannmur rundt LDAP.  Slipper bare inn UiO, nett med UiO-Unix-brukere, og litt annet.
• Strengere TLS.  De aller fleste vil ikke merke noe.
• Kortere timeouts p? forbindelsen n?r klienten ikke gj?r noe.

TIrsdag 19. mars (ferdig): Eksperimentelle endringer.

Si ifra hvis det oppst?r problemer, s? reverserer vi, og pr?ver kanskje igjen siden etter ? ha fikset.

• Klienter m? vite LDAP DN: "cn=system,dc=uio,dc=no", "dc=uio,dc=no" el.l.  Sl?r av "discovery" (namingContext) og default-DN i tjeneren.
  S?rlig Mac-er kan klage og vil trenge litt config.
• 129.240.<2,6>.* mister aksess til mreg-attributter 'uioHostContact' + 'uioHostDescription', unntatt de VLANs/maskiner som noen sier fremdeles trenger aksess.  Det er mange sm? VLANs der, og de trenger ikke alle aksess.  Poenget er bare ? luke ut un?dvendig aksess, ikke ? gj?re ting vanskeligere.  S? si ifra.  "ldap"-kanalen p? Mattermost er et bra sted ? diskutere unntak.  Kjente unntak: Kickstart og Nivlheim. Og kanskje drifts-vdi?
• Noen feilsituasjoner f?r feilkode noSuchObject (32) i stedet for tidligere insufficientAccessRights (50), i voip- og mail-tr?rne.  Det er allerede slik andre steder.
• TLS-justering: St?tter flere ec-algoritmer.  [Rettelse siden 1. versjon:] Denne delen er ikke "eksperimentell", den gamle algoritmen st?ttes fremdeles. Justeres kanskje litt mer onsdag 20. mars.

[Kansellert] Onsdag 20.mars: Kanskje videre TLS-justering.

Senere i ?r:

• Endre bl.a. OpenLDAP-default fra ldap://ldap.uio.no til ldaps:// p? klient-siden.
• Sperring av "ldap://" (port 389).
• Begrense aksess for anonyme forbindelser (de uten LDAP-bruker)

Sett i gang - ikke utsett, vi trenger oversikt for ? komme videre:

• Bruk "ldaps://" = LDAP over TLS (port 636), ikke ldap:// (port 389).
  Hvis kode m? endres, sl? samtidig av evt start_tls-operasjon (TLS over ldap://), siden TLS inni TLS ikke vil virke.
• For tjenester: Ikke bruk LDAP anonymt eller med bruker "public" eller "(pam-)common".  Bestill en LDAP-bruker i nettskjema.
  Poenget er logging, ikke sikkerhet.  Men bruker-autentisering trenger TLS.

Sistemann ut f?r frister ? forholde seg til.

Detaljer

Om TLS:

Klient-doc sier noen ganger "SSL" n?r de mener ldaps://, og "TLS" for StartTLS-operasjonen over ldap://-porten.  De mener neppe den eldgamle SSL-protokollen.  Den skal i s? fall feile, men be gjerne katalog-drift om ? sjekke i loggen.

Kode med start_tls:

Vil man ha kode som virker b?de over ldap:// og ldaps://, bytt ut
result = ldap_start_tls_s(ld, ...);
med
result = ldap_tls_inplace(ld) ? LDAP_SUCCESS : ldap_start_tls_s(ld, ...);
i C, eller omtrent (0 if URL.startswith("ldaps:") else ld.start_tls_s()) (python), eller litt mer kl?nete kode i Perl.

Strengere TLS:

Vil st?tte TLS-versjon 1.2 eller bedre, og TLS-ciphers if?lge Mozilla sin "intermediate compat" anbefaling.

Dessuten sender ikke tjeneren lenger rot-sertifikat.  Klienten m? kjenne dette.  Det har v?rt klager n?r vi har fjernet dette f?r, men det m? bort.