---
title: Seni Bina Integrasi OpenLDAP + Kerberos GSSAPI + TLS
---
flowchart BT
  subgraph Client["Klien"]
        A["kinit: Dapatkan tiket Kerberos"]
        B["ldapadd / ldapsearch<br>guna SASL GSSAPI"]
  end
  subgraph Network["Rangkaian"]
        TLS["Saluran TLS<br>SSL/TLS encryption"]
  end
  subgraph LDAP_Server["Pelayan OpenLDAP"]
        C["slapd: Konfigurasi TLS<br>dan SASL GSSAPI"]
        D["Keytab Kerberos<br>ldap.keytab"]
        E["ACL: Kawalan akses"]
        DB[("Pangkalan Data LDAP")]
  end
  subgraph KDC["Kerberos KDC"]
        F["Prinsipal ldap/hostname"]
        G["Pengeluaran tiket TGT & tiket servis"]
  end
    A -- Meminta TGT --> F
    F -- Mengeluarkan TGT --> A
    B -- Meminta tiket servis untuk LDAP --> G
    G -- Memberi tiket servis --> B
    B --> TLS
    TLS --> C
    C -- Sahkan tiket GSSAPI --> D
    C -- Periksa hak akses --> E
    E --> DB

OpenLDAP ialah perisian sumber terbuka yang menyediakan implementasi protokol Lightweight Directory Access Protocol (LDAP) untuk menyimpan dan mengurus data direktori secara terpusat, seperti maklumat pengguna, kumpulan, dan konfigurasi rangkaian.

Dalam konfigurasi ini, OpenLDAP diintegrasikan dengan SASL/GSSAPI melalui Kerberos untuk menyediakan mekanisme pengesahan yang selamat; bukan dengan kata laluan biasa, sebaliknya dengan menggunakan tiket.

Integrasi ini membolehkan pelayan LDAP menggunakan lapisan keselamatan TLS untuk menyulitkan komunikasi, manakala SASL/GSSAPI mengesahkan pengguna berdasarkan tiket Kerberos yang sah. Dengan ini, kata laluan tidak perlu dihantar melalui rangkaian, sekali gus mengurangkan risiko pendedahan.

Saya belum nampak sepenuhnya bagaimana mahu mengintegrasikannya dengan Hadoop. Saya fikir, mungkin hal ini memerlukan saya untuk mengkonfigurasikan Kerberos dengan OpenLDAP sebagai backend. Jadinya, saya hanya mulakan dengan asas konfigurasinya sahaja terlebih dahulu, sebagai proses perkenalan awal dengan OpenLDAP.

Keperluan Sistem

• Sistem operasi Linux (distribusi Arch Linux dan yang seangkatan dengannya).
• Pakej openldap, cyrus-sasl-gssapi dan sssd.
• Perkhidmatan Kerberos (KDC) telah dikonfigurasi dan berjalan dengan betul.
  

Konfigurasi SASL

TLS

• Jana sijil CA, sijil pelayan dan kunci peribadi pelayan dengan openssl. Rujuk Jana Sijil HTTPS untuk Domain yang Berasaskan ’localhost’ sebagai panduan asas. Ubah suai arahan penjanaan sijil dan kunci peribadi agar disimpan terus ke dalam direktori yang telah ditetapkan dalam config.ldif di bawah.

• Amat penting untuk memastikan bahawa sijil CA dipercayai oleh sistem. Jika tidak, perkhidmatan slapd dan sssd cenderung menemui kegagalan. Apa yang saya buat adalah dengan membuat symlink sijil CA itu ke dalam direktori berikut:

  bash

   sudo ln -s /etc/openldap/ssl/ca-cert.pem /usr/share/ca-certificates/trust-source/anchors/

• Sijil kemudian perlu dipercayai:

  bash

  sudo update-ca-trust

GSSAPI/Kerberos

• Tambah prinsipal servis ldap dengan “addprinc -randkey ldap/full.hostname”.

• Eksport kuncinya dengan arahan “ktadd -k /etc/openldap/ldap.keytab ldap/full.hostname”.

• Tetapan pemilikan direktori:

  bash

  chown ldap:ldap /etc/openldap/ldap.keytab
  chmod 600 /etc/openldap/ldap.keytab

• Eksport fail keytab di Terminal atau tambahkan entri berkenaan ke dalam .bashrc atau .zshrc jika menggunakan zsh.

  bash

  export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"

• Tambahkan fail bersama entri berikut:

  /etc/sasl2/slapd.conf

  mech_list: gssapi
  keytab: /etc/openldap/ldap.keytab

Konfigurasi Pelayan

• Saya ikuti langkah-langkah yang telah diterangkan di OpenLDAP - ArchWiki (Server Configuration).

• Kata laluan ditetapkan dari arahan slappasswd.

• Contoh config.ldif (disertakan komen ringkas sebagai deskripsi) :

  config.ldif

  # Root config (tetapan global slapd)
  dn: cn=config
  objectClass: olcGlobal
  cn: config
  olcArgsFile: /run/openldap/slapd.args
  olcPidFile: /run/openldap/slapd.pid
  # TLS config
  olcTLSCACertificateFile: /usr/share/ca-certificates/trust-source/anchors/ca-cert.pem
  olcTLSCACertificatePath: /usr/share/ca-certificates/trust-source/anchors
  olcTLSCertificateFile: /etc/openldap/ssl/server-cert.pem
  olcTLSCertificateKeyFile: /etc/openldap/ssl/server-key.pem
  olcTLSCipherSuite: HIGH:!aNULL:!MD5:@STRENGTH
  # SASL realm untuk integrasi Kerberos
  olcSaslRealm: EXAMPLE.COM
  
  # Schema container
  dn: cn=schema,cn=config
  objectClass: olcSchemaConfig
  cn: schema
  
  # {0} Skema core
  include: file:///etc/openldap/schema/core.ldif
  
  # {1} Skema cosine
  include: file:///etc/openldap/schema/cosine.ldif
  
  # {2} Skema NIS
  include: file:///etc/openldap/schema/nis.ldif
  
  # {3} Skema inetOrgPerson
  include: file:///etc/openldap/schema/inetorgperson.ldif
  
  # olcDatabase={0}config
  dn: olcDatabase={0}config,cn=config
  objectClass: olcDatabaseConfig
  olcDatabase: {0}config
  # ACL: SASL admin penuh, selain itu tiada
  olcAccess: {0}to *
    by dn.exact="uid=admin/admin,cn=example.com,cn=gssapi,cn=auth" manage
    by * none
  
  # olcDatabase={1}mdb: pangkalan data utama
  dn: olcDatabase={1}mdb,cn=config
  objectClass: olcDatabaseConfig
  objectClass: olcMdbConfig
  olcDatabase: {1}mdb
  olcSuffix: dc=example,dc=com
  olcRootDN: cn=admin,dc=example,dc=com
  olcRootPW: {SSHA}NPjeudwk3PxejhHYeq/L26I7lxE++bs5
  olcDbDirectory: /var/lib/openldap/openldap-data
  olcDbIndex: objectClass eq
  olcDbIndex: uid pres,eq
  olcDbIndex: mail pres,sub,eq
  olcDbIndex: cn,sn pres,sub,eq
  olcDbIndex: dc eq
  olcDbIndex: uidNumber,gidNumber eq
  # ACL 1: Kebenaran khusus untuk pengguna, admin & anonymous
  olcAccess: {0}to attrs=userPassword
    by dn.exact="uid=admin/admin,cn=example.com,cn=gssapi,cn=auth" manage
    by self write
    by anonymous auth
    by * none
  # ACL 2: Akses umum ke entri lain
  olcAccess: {1}to *
    by dn.exact="uid=admin/admin,cn=example.com,cn=gssapi,cn=auth" manage
    by dn="uid=host/hostname.example.com,cn=example.com,cn=gssapi,cn=auth" read
    by * none

  Penerangan tentang kandungan config.ldif :

  Fail ini mengandungi konfigurasi asas OpenLDAP (slapd) dalam format cn=config yang boleh terus dimuatkan dengan slapadd. Ia dibahagikan kepada beberapa bahagian utama:

  1. Global Config (dn: cn=config)

     Menyimpan tetapan global pelayan, seperti lokasi fail PID (olcPidFile) dan fail argumen (olcArgsFile).

     Termasuk konfigurasi TLS (olcTLSCACertificateFile, olcTLSCACertificatePath, olcTLSCertificateFile, olcTLSCertificateKeyFile, olcTLSCipherSuite) untuk mengaktifkan sambungan LDAP selamat melalui LDAPS atau StartTLS.

     ---

  2. Schema Container (dn: cn=schema,cn=config)

     Memuatkan empat skema asas menggunakan arahan include:

     • core : atribut asas LDAP seperti cn, sn, objectClass.
     • cosine : atribut tambahan seperti mail, description.
     • nis : atribut UNIX (cth. uidNumber, gidNumber, loginShell, homeDirectory). Atribut ini masih diperlukan untuk pemetaan akaun POSIX. Namun, jika menggunakan rfc2307bis, kumpulan didefinisikan dengan groupOfUniqueNames + uniqueMember dan tidak boleh digabungkan terus dengan posixGroup kerana kedua-duanya adalah structural classes.
     • inetorgperson : atribut moden pengguna seperti title, mobile.
       

     Arahan include ini memasukkan definisi skema dalam bentuk LDIF, yang diproses oleh slapd ketika memuatkan konfigurasi.

     ---

  3. Config Database (dn: olcDatabase={0}config,cn=config)

     Merupakan pangkalan data khas yang menyimpan metadata dan tetapan slapd.

     ACL menetapkan bahawa hanya SASL admin (uid=admin/admin,cn=example.com,cn=gssapi,cn=auth) dibenarkan mengurus semua tetapan, manakala pengguna lain tidak mempunyai akses.

     ---

  4. Primary MDB Database (dn: olcDatabase={1}mdb,cn=config)

     Pangkalan data utama yang menyimpan entri pengguna dan objek direktori (dc=example,dc=com).

     Tetapan penting termasuk olcSuffix (akar domain LDAP), olcRootDN (pengguna pentadbir direktori), olcRootPW (kata laluan pentadbir dalam format SSHA), lokasi storan (olcDbDirectory), dan indeks carian (olcDbIndex).

     Nota keselamatan: Gunakan olcRootPW hanya untuk ujian atau pembangunan. Dalam persekitaran produksi, hapuskan baris olcRootPW daripada config.ldif dan bergantung sepenuhnya kepada SASL/GSSAPI Kerberos untuk pentadbiran LDAP. Dengan itu, kata laluan statik tidak lagi disimpan di pelayan.

  
  

  ACL (Access Control List) :

  Dalam konfigurasi olcDatabase={1}mdb, terdapat dua peraturan ACL yang diutamakan:

  1. ACL {0} : Akses khusus atribut userPassword

     • Admin SASL (uid=admin/admin,...,cn=gssapi,cn=auth) mempunyai kawalan penuh (manage).

     • Pengguna boleh mengubah kata laluan sendiri (self write).

     • Pengguna anonymous dibenarkan menggunakannya untuk proses pengesahan (auth).

     • Lain-lain pengguna tidak mempunyai akses (none).

     Peraturan ini memastikan kata laluan hanya boleh diubah oleh pemilik akaun sendiri atau pentadbir SASL, manakala ia tetap boleh digunakan oleh anonymous untuk proses bind.

  2. ACL {1} : Akses umum kepada entri lain

     • Admin SASL mempunyai kawalan penuh (manage).

     • Hos prinsipal (uid=host/hostname.example.com,...,cn=gssapi,cn=auth) diberikan akses baca, sesuai untuk integrasi sistem atau aplikasi.

     • Akses selain itu ditolak (none).

     Dengan aturan ini, hanya data yang dibenarkan dapat dibaca oleh pengguna sah, manakala capaian oleh pihak luar tanpa autentikasi akan dinafikan.

  ---

  Melalui konfigurasi ini, pelayan LDAP telah sedia menerima sambungan selamat, menggunakan empat skema asas, dan mempunyai kawalan akses yang ketat bagi melindungi data serta memisahkan keistimewaan antara pengguna biasa, anonymous, dan admin SASL.
  

• Semak konfigurasi yang sudah ditambah:

  bash

  sudo slapcat -n 0 | less

• Tambahkan entri di bawah pada fail berikut:

  /etc/conf.d/slapd

  SLAPD_URLS="ldap://hostname.example.com ldapi:/// ldaps://hostname.example.com"
  SLAPD_OPTIONS=

• Sebelum memulakan perkhidmatan, pastikan direktori openldap dan slapd.d dimiliki oleh pengguna dan kumpulan ldap :

  bash

  sudo chown -R ldap:ldap /etc/openldap
  sudo chown -R ldap:ldap /etc/openldap/slapd.d

Konfigurasi Klien

• Edit fail ldap.conf :

  /etc/openldap/ldap.conf

  BASE            dc=example,dc=com
  URI             ldap://hostname.example.com ldapi:/// ldaps://hostname.example.com
  TLS_REQCERT allow
  TLS_CACERTDIR /usr/share/ca-certificates/trust-source/anchors

• Mulakan perkhidmatan:

  bash

  sudo systemctl start slapd

• Semak status sijil CA dengan arahan berikut:

  bash

  openssl s_client -connect hostname.example.com:636 -CAfile /usr/share/ca-certificates/trust-source/anchors/ca-cert.pem </dev/null

  Output mesti mempunyai entri berikut (antara entri terakhir direkodkan) :

  Verify return code: 0 (ok)
  

Percubaan

1. kinit sebagai admin kerberos :

   bash

   kinit admin/admin

2. Semak tiket.

   bash

   klist

   Ticket cache: KEYRING:persistent:1000:1000
   Default principal: admin/admin@EXAMPLE.COM
   
   Valid starting       Expires              Service principal
   08/09/2025 14:19:12  08/10/2025 00:19:12  krbtgt/EXAMPLE.COM@EXAMPLE.COM
           renew until 08/16/2025 14:19:10
   

3. Memandangkan konfigurasi awal telahpun memasukkan ACL (kebenaran penuh) untuk admin kerberos, boleh terus tambah data asas dan pengguna (lihat contoh entri base.ldif dan user_joe.ldif di LDAP authentication - ArchWiki) dengan menggunakan arahan-arahan di bawah:

   bash

   ldapadd -Y GSSAPI -H ldapi:/// -f base.ldif

   SASL/GSSAPI authentication started
   SASL username: admin/admin@EXAMPLE.COM
   SASL SSF: 256
   SASL data security layer installed.
   adding new entry "dc=example,dc=com"
   
   adding new entry "cn=admin,dc=example,dc=com"
   
   adding new entry "ou=People,dc=example,dc=com"
   
   adding new entry "ou=Groups,dc=example,dc=com"
   

   bash

   ldapadd -Y GSSAPI -H ldapi:/// -f user.ldif

   ...
   adding new entry "uid=admin,ou=People,dc=example,dc=com"
   

4. Sahkan dengan perintah berikut:

   bash

   ldapsearch -Y GSSAPI -H ldaps://hostname.example.com -b uid=admin,ou=People,dc=example,dc=com

   Pengeluaran yang dijangkakan:
   

   SASL/GSSAPI authentication started
   SASL username: admin/admin@EXAMPLE.COM
   SASL SSF: 256
   SASL data security layer installed.
   # extended LDIF
   #
   # LDAPv3
   # base <uid=admin,ou=People,dc=example,dc=com> with scope subtree
   # filter: (objectclass=*)
   # requesting: ALL
   #
   
   # admin, People, example.com
   dn: uid=admin,ou=People,dc=example,dc=com
   objectClass: top
   objectClass: person
   objectClass: organizationalPerson
   objectClass: inetOrgPerson
   objectClass: shadowAccount
   ...
   
   # search result
   search: 4
   result: 0 Success
   
   # numResponses: 2
   # numEntries: 1

   
   

5. Cuba kinit sebagai pengguna biasa pula. P/s: Pastikan cache tiket dimusnahkan dengan perintah kdestroy sebelum memulakan kinit.

6. Kenal pasti pengguna semasa:

   bash

   ldapwhoami -Y GSSAPI -H ldapi:///

   SASL/GSSAPI authentication started
   SASL username: user@EXAMPLE.COM
   SASL SSF: 256
   SASL data security layer installed.
   dn:uid=user,cn=example.com,cn=gssapi,cn=auth
   

7. Laksanakan semula ldapsearch sebagaimana di atas. Pengeluaran yang dijangkakan adalah seperti berikut (yang membuktikan bahawa pengguna biasa tidak mempunyai akses untuk membaca data ini melalui baris output, “result: 32 No such object”).
   

   SASL/GSSAPI authentication started
   SASL username: user@EXAMPLE.COM
   ...
   # LDAPv3
   # base <uid=admin,ou=People,dc=example,dc=com> with scope subtree
   # filter: (objectclass=*)
   # requesting: ALL
   #
   
   # search result
   search: 4
   result: 32 No such object
   
   # numResponses: 1

   
   

8. Dalam hal ini, jika mahu membolehkan pengguna biasa membaca data (tanpa kebenaran untuk mengubah), lakukan perubahan pada ACL sedia ada seperti berikut:

   edit_acl.ldif

   dn: olcDatabase={1}mdb,cn=config
   changetype: modify
   replace: olcAccess
   olcAccess: {0}to attrs=userPassword
     by dn.exact="uid=admin/admin,cn=example.com,cn=gssapi,cn=auth" manage
     by self write
     by anonymous auth
     by * none
   olcAccess: {1}to *
     by dn.exact="uid=admin/admin,cn=example.com,cn=gssapi,cn=auth" manage
     by dn="uid=host/hostname.example.com,cn=example.com,cn=gssapi,cn=auth" read
     by users read
     by * none

   Selepas itu, aktikan perubahan dengan arahan berikut:

   bash

   ldapmodify -Y GSSAPI -H ldapi:/// -f edit_acl.ldif

Autentikasi dalam Talian dengan SSSD

1. Saya ikuti panduan yang diberikan di Online and offline authentication with SSSD - ArchWiki.

2. Berikut adalah kandungan fail konfigurasi sssd saya:

   /etc/sssd/sssd.conf

   [sssd]
   services = nss, pam
   domains = LDAP
   
   [nss]
   
   [pam]
   
   [domain/LDAP]
   id_provider = ldap
   auth_provider = krb5
   chpass_provider = krb5
   access_provider = ldap
   
   # --- LDAP settings ---
   ldap_uri = ldaps://hostname.example.com
   ldap_search_base = ou=People,dc=example,dc=com
   ldap_id_use_start_tls = false
   ldap_tls_reqcert = demand
   ldap_tls_cacert = /usr/share/ca-certificates/trust-source/anchors/ca-cert.pem
   ldap_sasl_mech = GSSAPI
   ldap_sasl_authid = host/hostname.example.com
   ldap_krb5_keytab = /etc/krb5.keytab
   ldap_referrals = false
   
   # --- Kerberos settings ---
   krb5_server = hostname.example.com
   krb5_realm = EXAMPLE.COM
   
   # Uncomment if you need offline logins
   #cache_credentials = true
   
   enumerate = false
   debug_level = 9
   
   # Other LDAP servers may support this instead (modern approach)
   ldap_schema = rfc2307bis
   ldap_group_member = uniqueMember
   
   # OpenLDAP supports posixGroup (classic approach), uncomment the following two lines
   # to get group membership support (and comment the other conflicting parameters)
   #ldap_schema = rfc2307
   #ldap_group_member = memberUid

3. Setelah selesai konfigurasi-konfigurasi yang diperlukan sebagaimana panduan, mulakan servis sssd.

   bash

   sudo systemctl start sssd

   Semakan status antaranya akan memaparkan:

   hostname sssd_be: GSSAPI client step 1
   hostname sssd_be: GSSAPI client step 2
   

   Manakala log /var/log/sssd/sssd_LDAP.log pula akan mempunyai entri berikut:

   [be[LDAP]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/hostname.example.com
   [be[LDAP]] [sdap_cli_connect_recv] (0x0400): Connection established.
   

Bagaimana Menyemak Kejayaan Integrasi antara SSSD, LDAP dan GSSAPI?

Untuk mengesahkan bahawa integrasi berjalan dengan betul, beberapa ujian boleh dilakukan. Setiap arahan menghasilkan kesan berbeza sama ada pada log sssd mahupun output terminal.

Contoh log apabila id user atau groups user dipanggil:

[be[LDAP]] [dp_req_reply_std] (0x1000): [RID#20] DP Request [Initgroups #20]: Returning [Success]: 0,0,Success
[be[LDAP]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo on /sssd from sssd.nss: Success
[be[LDAP]] [sdap_process_result] (0x2000): Trace: sh[0x5560f38bbe70], connected[1], ops[(nil)], ldap[0x5560f37f67f0]

  
  ---
title: Urutan Autentikasi SSSD + Kerberos + OpenLDAP
---
sequenceDiagram
  participant U as Pengguna 
  participant K as Kerberos KDC
  participant S as SSSD
  participant L as LDAP (slapd)
  U->>K: kinit (minta tiket TGT)
  K-->>U: Hantar TGT
  U->>S: id / groups / getent
  S->>L: SASL bind (GSSAPI)
  L-->>S: Respons berjaya<br>(berdasarkan tiket + ACL)
  S-->>U: Papar info<br>pengguna/kumpulan