Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah AWS Microsoft AD yang Dikelola
Berikut ini dapat membantu Anda memecahkan masalah umum yang mungkin Anda temui saat membuat atau menggunakan Direktori Aktif AWS Microsoft AD Terkelola.
## Masalah dengan Microsoft AD yang AWS Dikelola
Beberapa tugas pemecahan masalah hanya dapat diselesaikan oleh. Dukungan Berikut adalah beberapa tugasnya:
+ Mulai ulang pengontrol domain Directory Service yang disediakan.
+ [Memutakhirkan Microsoft AD yang AWS Dikelola](ms_ad_upgrade_edition.md).
Untuk membuat kasus dukungan, lihat [Membuat kasus dukungan dan manajemen kasus](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
## Masalah dengan Netlogon dan komunikasi saluran aman
Sebagai mitigasi terhadap [CVE-2020-1472](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472), Microsoft telah merilis patching yang memodifikasi cara komunikasi saluran aman Netlogon diproses oleh pengontrol domain. Sejak diperkenalkannya perubahan Netlogon aman ini, beberapa koneksi Netlogon (server, workstation, dan validasi kepercayaan) mungkin tidak diterima oleh Microsoft AD yang Dikelola Anda. AWS
Untuk memverifikasi apakah masalah Anda terkait dengan Netlogon atau komunikasi saluran aman, cari CloudWatch Log Amazon Anda untuk peristiwa IDs 5827 (untuk masalah terkait otentikasi perangkat) atau 5828 (untuk masalah terkait validasi kepercayaan AD). Untuk selengkapnya tentang CloudWatch di Microsoft AD yang AWS Dikelola, lihat[Mengaktifkan penerusan CloudWatch log Amazon Logs untuk Microsoft AD yang Dikelola AWS](ms_ad_enable_log_forwarding.md).
Untuk informasi lebih lanjut tentang mitigasi terhadap CVE-2020-1472, lihat [Cara mengelola perubahan dalam koneksi saluran aman Netlogon yang terkait dengan CVE-2020-1472 di situs web](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e). Microsoft
## Anda menerima kesalahan 'Status Respons: 400 Permintaan Buruk' saat mencoba mengatur ulang kata sandi pengguna
Anda menerima pesan galat yang mirip dengan berikut ini saat mencoba mengatur ulang kata sandi pengguna:
`Response Status: 400 Bad Request`
Anda mungkin mengalami masalah ini ketika ada objek duplikat di Unit Organisasi Microsoft AD AWS Terkelola (OU) dengan nama login pengguna yang identik. Nama logon pengguna harus unik. Lihat [Memecahkan masalah Data Direktori](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727059(v=technet.10)?redirectedfrom=MSDN) dalam Microsoft dokumentasi untuk informasi selengkapnya.
## Pemulihan kata sandi
Jika pengguna lupa kata sandi atau mengalami masalah saat masuk ke direktori Microsoft AD AWS Terkelola, Anda dapat mengatur ulang kata sandi mereka menggunakan file Konsol Manajemen AWS, PowerShell atau file. AWS CLI
Untuk informasi selengkapnya, lihat [Menyetel ulang kata sandi pengguna Microsoft AD yang AWS Dikelola](ms_ad_manage_users_groups_reset_password.md).
## Sumber daya tambahan
Sumber daya berikut dapat membantu Anda memecahkan masalah saat Anda bekerja dengannya. AWS
+ **[AWS Pusat Pengetahuan](https://aws.amazon.com/premiumsupport/knowledge-center/)** —Temukan FAQs dan tautkan ke sumber daya lain untuk membantu Anda memecahkan masalah.
+ **[AWS Support Center](https://console.aws.amazon.com/support/home#/)** —Dapatkan dukungan teknis.
+ **[AWS Pusat Support Premium](https://aws.amazon.com/premiumsupport/)** —Dapatkan dukungan teknis premium.
Sumber daya berikut dapat membantu Anda memecahkan masalah Active Directory yang umum.
+ [Dokumentasi Direktori Aktif](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-overview)
+ [AD DS Memecahkan masalah](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting)
**Topics**
+ [Masalah dengan Microsoft AD yang AWS Dikelola](#general_issues)
+ [Masalah dengan Netlogon dan komunikasi saluran aman](#ms_ad_tshoot_netlogon_issues)
+ [Anda menerima kesalahan 'Status Respons: 400 Permintaan Buruk' saat mencoba mengatur ulang kata sandi pengguna](#ms_ad_tshoot_reset_password)
+ [Pemulihan kata sandi](#ms_ad_tshoot_password_recovery)
+ [Sumber daya tambahan](#troubleshoot_general_resources)
+ [Kesalahan gabungan domain instans Amazon EC2 Linux](ms_ad_troubleshooting_join_linux.md)
+ [AWS Microsoft AD yang dikelola ruang penyimpanan rendah yang tersedia](ms_ad_troubleshooting_low_storage_space.md)
+ [Kesalahan ekstensi skema](ms_ad_troubleshooting_schema.md)
+ [Alasan status pembuatan kepercayaan](ms_ad_troubleshooting_trusts.md)
+ [Pemecahan Masalah AWS Pemanfaatan CPU tinggi Microsoft AD yang Dikelola](ms_ad_troubleshooting_high_cpu.md)
# Kesalahan gabungan domain instans Amazon EC2 Linux
Berikut ini dapat membantu Anda memecahkan masalah beberapa pesan galat yang mungkin Anda temui saat menggabungkan instans Amazon EC2 Linux ke direktori AD Microsoft AWS Terkelola.
## Instans Linux tidak dapat menggabungkan domain atau mengautentikasi
Instans Ubuntu 14.04, 16.04, dan 18.04 *harus* reverse-resolvable di DNS sebelum ranah dapat bekerja dengan Microsoft Active Directory. Jika tidak, Anda mungkin akan menjumpai salah satu dari dua skenario berikut:
### Skenario 1: Instans Ubuntu yang belum bergabung ke ranah
Untuk instans Ubuntu yang mencoba bergabung dengan ranah, perintah `sudo realm join` mungkin tidak memberikan izin yang diperlukan untuk menggabungkan domain dan mungkin menampilkan kesalahan berikut:
\$1 Tidak dapat mengautentikasi ke direktori aktif: SASL (-1): kegagalan generik: GSSAPI Kesalahan: Nama yang tidak valid diberikan (Sukses) adcli: tidak dapat terhubung ke EXAMPLE.COM domain: Tidak dapat mengautentikasi ke direktori aktif: SASL (-1): kegagalan generik: GSSAPI Kesalahan: Nama yang tidak valid diberikan (Sukses)\$1 Izin tidak mencukupi untuk bergabung dengan ranah domain: Tidak dapat bergabung dengan ranah: Izin tidak mencukupi untuk bergabung dengan domain
### Skenario 2: Instans Ubuntu yang bergabung ke ranah
Untuk instance Ubuntu yang sudah bergabung dengan domain Microsoft Active Directory, upaya SSH ke instance menggunakan kredenal domain mungkin gagal dengan kesalahan berikut:
\$1 ssh admin@EXAMPLE.COM @198 .51.100
tidak ada identitas seperti itu:/Users/username/.ssh/id\$1ed25519: Tidak ada file atau direktori seperti itu
Kata sandi admin@EXAMPLE.COM @198 .51.100:
Izin ditolak, silakan coba lagi.
Kata sandi admin@EXAMPLE.COM @198 .51.100:
Jika Anda masuk ke instans dengan kunci publik dan mencentang `/var/log/auth.log`, Anda mungkin melihat kesalahan berikut tentang tidak dapat menemukan pengguna:
12 Mei 01:02:12 ip-192-0-2-0 sshd [2251]: pam\$1unix (sshd: auth): kegagalan otentikasi; nama log = uid = 0 euid = 0 tty = ssh ruser = rhost = 203.0.113.0
12 Mei 01:02:12 ip-192-0-2-0 sshd [2251]: pam\$1sss (sshd: auth): kegagalan otentikasi; nama log = uid = 0 euid = 0 tty = ssh ruser= rhost = 203.0.113.0 pengguna = admin@EXAMPLE.COM
12 Mei 01:02:12 ip-192-0-2-0 sshd [2251]: pam\$1sss (sshd:auth): diterima untuk pengguna admin@EXAMPLE.COM: 10 (Pengguna tidak diketahui modul otentikasi yang mendasarinya)
12 Mei 01:02:14 ip-192-0-2-0 sshd [2251]: Kata sandi gagal untuk pengguna yang tidak valid admin@EXAMPLE.COM dari 203.0.113.0 port 13344 ssh2
12 Mei 01:02:15 ip-192-0-2-0 sshd [2251]: Koneksi ditutup oleh 203.0.113.0 [preauth]
Namun, `kinit` untuk pengguna masih bekerja. Lihat contoh ini:
ubuntu @ip -192-0-2-0: \$1\$1 kinit admin@EXAMPLE.COM Kata sandi untuk admin@EXAMPLE.COM: ubuntu @ip -192-0-2-0: \$1\$1 klist Cache tiket: FILE: /tmp/krb5cc\$11000 Prinsip default: admin@EXAMPLE.COM
### Solusi
Solusi yang direkomendasikan saat ini untuk kedua skenario ini adalah untuk menonaktifkan DNS terbalik di `/etc/krb5.conf` di bagian [libdefaults] seperti yang ditunjukkan di bawah ini:
```
[libdefaults]
default_realm = EXAMPLE.COM
rdns = false
```
## Masalah autentikasi kepercayaan satu arah dengan penggabungan domain secara mulus.
Jika Anda memiliki kepercayaan keluar satu arah yang dibuat antara iklan Microsoft AWS Terkelola dan Direktori Aktif lokal, Anda mungkin mengalami masalah autentikasi saat mencoba mengautentikasi terhadap instance Linux yang bergabung dengan domain menggunakan kredensi Direktori Aktif tepercaya Anda dengan Winbind.
### Kesalahan
31 Juli 00:00:00 EC2 AMAZ- LSMWq T sshd [23832]: Kata sandi gagal untuk user@corp.example.com dari xxx.xxx.xxx.xxx port 18309 ssh2
31 Jul 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd: auth): mendapatkan kata sandi (0x00000390)
31 Jul 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd:auth): pam\$1get\$1item mengembalikan kata sandi
31 Jul 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd:auth): permintaan wbcLogonUser gagal: WBC\$1ERR\$1AUTH\$1ERROR, kesalahan PAM: PAM\$1SYSTEM\$1ERR (4), NTSTATUS: \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, Pesan kesalahan adalah: Nama objek tidak ditemukan.
31 Juli 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd:auth): kesalahan modul internal (retval = PAM\$1SYSTEM\$1ERR (4), pengguna = 'CORP\$1 user')
## Solusi
Untuk mengatasi masalah ini, Anda perlu untuk mengomentari atau menghapus direktif dari file konfigurasi modul PAM (`/etc/security/pam_winbind.conf`) menggunakan langkah-langkah berikut.
1. Buka file `/etc/security/pam_winbind.conf` di editor teks.
```
sudo vim /etc/security/pam_winbind.conf
```
1. Mengomentari atau menghapus direktif berikut **krb5\$1auth = yes**.
```
[global]
cached_login = yes
krb5_ccache_type = FILE
#krb5_auth = yes
```
1. Menghentikan layanan Winbind, dan kemudian mulai lagi.
```
service winbind stop or systemctl stop winbind
net cache flush
service winbind start or systemctl start winbind
```
# AWS Microsoft AD yang dikelola ruang penyimpanan rendah yang tersedia
Jika iklan Microsoft AWS Terkelola Anda terganggu karena Active Directory memiliki ruang penyimpanan yang tersedia rendah, tindakan segera diperlukan untuk mengembalikan direktori ke status aktif. Dua penyebab paling umum dari gangguan ini dibahas pada bagian di bawah ini:
1. [Folder SYSVOL menyimpan lebih dari objek kebijakan grup yang esensial](#sysvol-folder-gpo)
1. [Basis data Direktori Aktif telah mengisi volume](#ad-db-filled-volume)
Untuk informasi harga tentang penyimpanan Microsoft AD AWS Terkelola, lihat [Directory Service Harga](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).
## Folder SYSVOL menyimpan lebih dari objek kebijakan grup yang esensial
Penyebab umum dari gangguan ini adalah karena untuk menyimpan file yang non-esensial untuk pemrosesan kebijakan grup di folder SYSVOL. File-file yang tidak penting ini dapat berupa EXEs MSIs,, atau file lain yang tidak penting untuk diproses oleh Kebijakan Grup. Objek penting untuk memproses Kebijakan Grup adalah Objek Kebijakan Grup, Logon/off Skrip, dan [objek Central Store for Group Policy](https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store). File yang tidak penting harus disimpan di server file selain pengontrol domain Microsoft AD yang AWS Dikelola.
Jika file untuk [Instalasi Perangkat Lunak Kebijakan Grup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software) diperlukan Anda harus menggunakan server file untuk menyimpan file-file instalasi tersebut. Jika Anda memilih untuk tidak mengelola sendiri server file, AWS menyediakan opsi server file terkelola, [Amazon FSx](https://aws.amazon.com/fsx/).
Untuk menghapus file yang tidak perlu, Anda dapat mengakses berbagi SYSVOL melalui jalur konvensi penamaan universal (UNC). Misalnya, jika nama domain yang sepenuhnya memenuhi syarat (FQDN) domain Anda adalah example.com, jalur UNC untuk SYSVOL adalah "\$1\$1example.local\$1SYSVOL\$1example.local\$1”. Setelah Anda menemukan dan menghapus objek yang non-esensial bagi kebijakan grup untuk memproses direktori, itu akan kembali ke keadaan Aktif dalam waktu 30 menit. Jika setelah 30 menit direktori tidak aktif, silakan hubungi AWS Support.
Menyimpan file Kebijakan Grup penting saja di bagian SYSVOL Anda akan memastikan bahwa Anda tidak akan mengganggu direktori Anda karena SYSVOL penuh.
## Basis data Direktori Aktif telah mengisi volume
Penyebab umum dari gangguan ini adalah karena basis data Direktori Aktif memenuhi volume. Untuk memverifikasi apakah ini masalahnya, Anda dapat meninjau jumlah **total** objek dalam direktori anda. Kami menebalkan kata **total** untuk memastikan bahwa Anda memahami objek yang **dihapus** masih dihitung dalam jumlah total objek dalam sebuah direktori.
Secara default Microsoft AD yang AWS Dikelola menyimpan item di Tempat Daur Ulang AD selama 180 hari sebelum menjadi Objek Daur Ulang. Setelah objek menjadi Objek-Daur ulang (tombstoned), objek itu dipertahankan selama 180 hari sebelum akhirnya dibersihkan dari direktori. Jadi ketika sebuah objek dihapus itu ada di dalam basis data direktori untuk 360 hari sebelum dibersihkan. Inilah sebabnya mengapa jumlah total objek perlu dievaluasi.
Untuk detail selengkapnya tentang jumlah objek yang didukung Microsoft AD yang AWS dikelola, lihat [Directory Service Harga](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).
Untuk mendapatkan jumlah total objek dalam direktori yang menyertakan objek yang dihapus, Anda dapat menjalankan PowerShell perintah berikut dari instance Windows yang bergabung dengan domain. Untuk langkah-langkah cara mengatur instans pengelolaan, lihat [Manajemen pengguna dan grup di Microsoft AD yang AWS Dikelola](ms_ad_manage_users_groups.md).
```
Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object -Property 'Count' | Select-Object -Property 'Count'
```
Di bawah ini adalah contoh output dari perintah di atas:
```
Count
10000
```
Jika jumlah total di atas jumlah objek yang didukung untuk ukuran direktori yang tercantum dalam catatan di atas, Anda telah melampaui kapasitas direktori Anda.
Di bawah ini adalah pilihan untuk mengatasi gangguan ini:
1. Pembersihan AD
1. Menghapus objek AD yang tidak diinginkan.
1. Menghapus objek yang tidak diinginkan dari Keranjang Sampah AD. Ingat bahwa ini merusak dan satu-satunya cara untuk memulihkan objek yang dihapus itu adalah dengan melakukan pemulihan direktori.
1. Perintah berikut akan menghapus semua objek yang dihapus dari Keranjang Sampah AD.
**penting**
Gunakan perintah ini dengan hati-hati karena ini merusak dan satu-satunya cara untuk memulihkan objek yang dihapus itu adalah dengan melakukan pemulihan direktori.
```
$DomainInfo = Get-ADDomain
$BaseDn = $DomainInfo.DistinguishedName
$NetBios = $DomainInfo.NetBIOSName
$ObjectsToRemove = Get-ADObject -Filter { isDeleted -eq $true } -IncludeDeletedObjects -SearchBase "CN=Deleted Objects,$BaseDn" -Properties 'LastKnownParent','DistinguishedName','msDS-LastKnownRDN' | Where-Object { ($_.LastKnownParent -Like "*OU=$NetBios,$BaseDn") -or ($_.LastKnownParent -Like '*\0ADEL:*') }
ForEach ($ObjectToRemove in $ObjectsToRemove) { Remove-ADObject -Identity $ObjectToRemove.DistinguishedName -IncludeDeletedObjects }
```
1. Buka kasing dengan AWS Support untuk meminta yang Directory Service merebut kembali ruang kosong.
1. Jika jenis direktori Anda adalah Edisi Standar Buka kasus dengan AWS Support yang meminta direktori Anda ditingkatkan ke Enterprise Edition. Ini juga akan meningkatkan biaya direktori Anda. Untuk informasi harga, lihat [Harga Directory Service](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).
Di Microsoft AD yang AWS Dikelola, anggota grup **Administrator Seumur Hidup Objek yang Dihapus AWS Delegasi** memiliki kemampuan untuk mengubah `msDS-DeletedObjectLifetime` atribut yang menetapkan jumlah waktu dalam hari objek yang dihapus disimpan di Tempat Daur Ulang AD sebelum menjadi Objek Daur Ulang.
**catatan**
Ini adalah topik lanjutan. Jika dikonfigurasi secara tidak tepat, dapat mengakibatkan kehilangan data. Kami sangat menyarankan Anda untuk meninjau terlebih dulu [Keranjang Sampah AD: Memahami, Menerapkan, Praktik Terbaik, dan Pemecahan Masalah](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944) untuk mendapatkan pemahaman yang lebih baik tentang proses-proses ini.
Kemampuan untuk mengubah nilai atribut `msDS-DeletedObjectLifetime` ke angka yang lebih rendah dapat membantu memastikan jumlah objek Anda tidak melebihi tingkat yang didukung. Nilai valid terendah atribut ini dapat diatur ke adalah 2 hari. Setelah nilai tersebut melampaui Anda tidak akan lagi dapat memulihkan objek yang dihapus menggunakan Keranjang Sampah AD. Ini akan perlu memulihkan direktori Anda dari snapshot untuk memulihkan objek. Untuk informasi selengkapnya, lihat [Memulihkan iklan Microsoft AWS Terkelola Anda dengan snapshot](ms_ad_snapshots.md). **Setiap pemulihan dari snapshot dapat mengakibatkan hilangnya data karena merupakan titik waktu.**
Untuk mengubah Masa Hidup Objek yang Dihapus dari direktori Anda jalankan perintah berikut:
**catatan**
Jika Anda menjalankan perintah seperti adanya, itu akan mengatur nilai atribut Masa Hidup Objek yang Dihapus untuk 30 hari. Jika Anda ingin membuatnya lebih panjang atau lebih pendek ganti “30" dengan nomor apa pun yang Anda inginkan. Namun, kami merekomendasikan agar Anda tidak mengaturnya lebih dari angka default 180.
```
$DeletedObjectLifetime = 30
$DomainInfo = Get-ADDomain
$BaseDn = $DomainInfo.DistinguishedName
Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$BaseDn" -Partition "CN=Configuration,$BaseDn" -Replace:@{"msDS-DeletedObjectLifetime" = $DeletedObjectLifetime}
```
# Kesalahan ekstensi skema
Berikut ini dapat membantu Anda memecahkan masalah beberapa pesan galat yang mungkin Anda temui saat memperluas skema untuk direktori AWS Microsoft AD yang Dikelola.
## Referensi
**Kesalahan**
*Menambahkan kesalahan pada entri yang dimulai pada baris 1: Referral Kesalahan sisi server adalah: 0x202b Referral dikembalikan dari server. Kesalahan server yang diperluas adalah: 0000202B: RefErr: DSID-0310082F, data 0, 1 titik akses\$1 tref 1: 'example.com' Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
Pastikan bahwa semua bidang nama yang dibedakan memiliki nama domain yang benar. Dalam contoh di atas, `DC=example,dc=com` harus diganti dengan `DistinguishedName` yang ditunjukkan oleh cmdlet `Get-ADDomain`.
## Tidak dapat membaca file impor
**Kesalahan**
*Tidak dapat membaca file impor Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
File LDIF yang diimpor kosong (0 byte). Pastikan file yang benar telah diunggah.
## Kesalahan sintaks
**Kesalahan**
*Ada kesalahan sintaks dalam file input Gagal pada baris 21. Token terakhir dimulai dengan 'q'. Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
Teks pada baris 21 tidak diformat dengan benar. Huruf pertama dari teks yang tidak valid adalah `A`. Memperbarui baris 21 dengan sintaks LDIF valid. Untuk informasi selengkapnya tentang format file dalam jumlah besar, lihat [Langkah 1: Buat file LDIF Anda](create.md).
## Atribut atau nilai ada
**Kesalahan**
*Menambahkan kesalahan pada entri yang dimulai pada baris 1: Atribut atau Nilai Ada Kesalahan sisi server adalah: 0x2083 nilai yang ditentukan sudah ada. Kesalahan server yang diperluas adalah: 00002083:: DSID-03151830, \$11 AtrErr:\$1 t0:00002083: DSID-03151830, masalah 1006 (ATT\$1OR\$1VALUE\$1EXISTS), data 0, Att 20019 (MayContain) :len 4 Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
Perubahan skema telah diterapkan.
## Tidak ada atribut tersebut
**Kesalahan**
*Menambahkan kesalahan pada entri yang dimulai pada baris 1: Tidak Ada Atribut Tersebut Kesalahan sisi server adalah: 0x2085 Nilai atribut tidak dapat dihapus karena tidak ada pada objek. Kesalahan server yang diperluas adalah: 00002085:: DSID-03152367, \$11 AtrErr:\$1 t0:00002085: DSID-03152367, masalah 1001 (NO\$1ATTRIBUTE\$1OR\$1VAL), data 0, Att 20019 (MayContain) :len 4 Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
File LDIF mencoba untuk menghapus atribut dari kelas, tapi atribut saat ini tidak melekat pada kelas. Perubahan skema mungkin sudah diterapkan.
**Kesalahan**
*Menambahkan kesalahan pada entri mulai pada baris 41: Tidak ada atribut tersebut 0x57 Parameter tidak benar. Kesalahan server yang diperpanjang adalah: 0x208d Objek direktori tidak ditemukan. Kesalahan server yang diperluas adalah: “00000057:: DSID-0C090D8A, komentar LdapErr: Kesalahan dalam operasi konversi atribut, data 0, v2580" Jumlah Objek Dimodifikasi: 0*
**Pemecahan masalah**
Atribut yang tercantum pada baris 41 tidak benar. Periksa kembali ejaannya.
## Tidak ada objek tersebut
**Kesalahan**
*Menambahkan kesalahan pada entri mulai pada baris 1: Tidak Ada Objek Tersebut Kesalahan sisi server adalah: 0x208d Objek direktori tidak ditemukan. Kesalahan server yang diperluas adalah: 0000208D: NameErr: DSID-03100238, masalah 2001 (NO\$1OBJECT), data 0, kecocokan terbaik: 'Cn = Skema, CN = konfigurasi, DC = Contoh, DC = com' Jumlah Objek yang Dimodifikasi: 0*
**Pemecahan masalah**
Objek yang direferensikan oleh nama yang dibedakan (DN) tidak ada.
# Alasan status pembuatan kepercayaan
Jika pembuatan kepercayaan gagal untuk Microsoft AD yang AWS Dikelola, pesan status berisi informasi tambahan. Berikut ini dapat membantu Anda memahami apa arti pesan-pesan itu.
## Akses ditolak
Akses ditolak ketika mencoba untuk membuat kepercayaan. Entah kata sandi kepercayaan salah atau pengaturan keamanan domain jarak jauh tidak memungkinkan kepercayaan untuk dikonfigurasi. Untuk informasi lebih lanjut tentang trust, lihat[Meningkatkan Efisiensi Kepercayaan dengan Nama Situs dan DCLocator](#enhancing-trust-site-names). Untuk menyelesaikan masalah ini, coba hal berikut:
+ Verifikasi bahwa Anda menggunakan kata sandi kepercayaan yang sama yang Anda gunakan saat membuat kepercayaan yang sesuai pada domain jarak jauh.
+ Verifikasi bahwa pengaturan keamanan domain Anda mengizinkan pembuatan kepercayaan.
+ Verifikasi bahwa kebijakan keamanan lokal Anda diatur dengan benar. Periksa secara khusus `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously` dan pastikan bahwa itu berisi setidaknya tiga pipe bernama berikut:
+ netlogon
+ samr
+ lsarpc
+ Verifikasi bahwa pipa bernama di atas ada sebagai nilai pada kunci **NullSessionPipes**registri yang ada di jalur registri **HKLM\$1 SYSTEM\$1\$1 services\$1CurrentControlSet\$1 Parameters LanmanServer**. Nilai-nilai ini harus disisipkan pada baris yang terpisah.
**catatan**
Secara default, `Network access: Named Pipes that can be accessed anonymously` tidak diatur dan akan menampilkan `Not Defined`. Ini adalah normal, sebagai pengendali domain efektif pengaturan default untuk `Network access: Named Pipes that can be accessed anonymously` adalah `netlogon`, `samr`, `lsarpc`.
+ Verifikasi Pengaturan Penandatanganan Blok Pesan Server (SMB) berikut dalam Kebijakan *Pengontrol Domain Default*. Pengaturan ini dapat ditemukan di bawah **Konfigurasi Komputer>** **Pengaturan Windows> Pengaturan** Keamanan> **Kebijakan Lokal/Opsi** **Keamanan**. Mereka harus cocok dengan pengaturan berikut:
+ Microsoftklien jaringan: Komunikasi tanda tangani secara digital (selalu): Default: Diaktifkan
+ Microsoftserver jaringan: Komunikasi tanda tangani secara digital (selalu): Diaktifkan
### Meningkatkan Efisiensi Kepercayaan dengan Nama Situs dan DCLocator
Nama Situs Pertama seperti Default-First-Site-Name bukan persyaratan untuk membangun hubungan kepercayaan antar domain. Namun, menyelaraskan nama situs antar domain dapat secara signifikan meningkatkan efisiensi proses Domain Controller Locator ()DCLocator. Penyelarasan ini meningkatkan prediksi dan pengendalian pemilihan pengendali domain di seluruh perwalian hutan.
DCLocator Proses ini sangat penting untuk menemukan pengontrol domain di berbagai domain dan hutan. Untuk informasi lebih lanjut tentang DCLocator proses, lihat [Microsoftdokumentasi](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-location-issues). Konfigurasi situs yang efisien memungkinkan lokasi pengontrol domain yang lebih cepat dan akurat, yang mengarah pada kinerja dan keandalan yang lebih baik dalam operasi lintas hutan.
Untuk informasi selengkapnya tentang cara nama situs dan DCLocator proses berinteraksi, lihat Microsoft artikel berikut:
+ [Bagaimana Pengontrol Domain Berlokasi di Seluruh Perwalian](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180)
+ [Pencari Lokasi Domain Lintas Hutan](https://techcommunity.microsoft.com/blog/askds/domain-locator-across-a-forest-trust/395689)
## Nama domain yang ditentukan tidak ada atau tidak dapat dihubungi
Untuk mengatasi masalah ini, pastikan pengaturan grup keamanan untuk domain dan daftar kontrol akses (ACL) untuk VPC Anda sudah benar dan Anda telah memasukkan informasi untuk forwarder bersyarat Anda secara akurat. AWS mengkonfigurasi grup keamanan untuk membuka hanya port yang diperlukan untuk komunikasi Active Directory. Dalam konfigurasi default, grup keamanan menerima lalu lintas ke port-port ini dari alamat IP mana pun. Lalu lintas keluar dibatasi untuk grup keamanan. Anda perlu memperbarui aturan keluar pada grup keamanan untuk mengizinkan lalu lintas ke jaringan on-premise Anda. Untuk informasi lebih lanjut tentang persyaratan keamanan, silakan lihat[Langkah 2: Siapkan Microsoft AD yang AWS Dikelola](ms_ad_tutorial_setup_trust_prepare_mad.md).
![\[Edit grup keamanan\]](http://docs.aws.amazon.com/id_id/directoryservice/latest/admin-guide/images/edit_security_group.png)
Jika server DNS untuk jaringan direktori lain menggunakan alamat IP publik (non-RFC 1918), Anda perlu menambahkan rute IP pada direktori dari konsol Directory Services untuk Server DNS. Untuk informasi selengkapnya, lihat [Membuat, memverifikasi, atau menghapus hubungan kepercayaan](ms_ad_setup_trust.md#trust_steps) dan [Prasyarat](ms_ad_setup_trust.md#trust_prereq).
Internet Assigned Numbers Authority (IANA) telah menyediakan tiga blok dari ruang alamat IP berikut untuk internet pribadi:
+ 10.0.0.0 - 10.255.255.255 (prefiks 10/8)
+ 172.16.0.0 - 172.31.255.255 (prefiks 172.16/12)
+ 192.168.0.0 - 192.168.255.255 (prefiks 192.168/16)
Untuk informasi lebih lanjut, lihat [https://tools.ietf.org/html/rfc1918](https://tools.ietf.org/html/rfc1918).
Verifikasi bahwa **Nama Situs AD Default** untuk iklan Microsoft AWS Terkelola cocok dengan **Nama Situs AD Default** di infrastruktur lokal Anda. Komputer menentukan nama situs menggunakan domain yang di mana komputer adalah anggota, bukan domain pengguna. Mengganti nama situs agar sesuai dengan on-premise terdekat memastikan pencari lokasi DC akan menggunakan pengendali domain dari situs terdekat. Jika ini tidak menyelesaikan masalah, ada kemungkinan bahwa informasi dari penerus bersyarat yang dibuat sebelumnya telah di-cache, mencegah pembuatan kepercayaan baru. Tunggu beberapa menit, dan kemudian coba buat kepercayaan dan penerus bersyarat lagi.
Untuk informasi selengkapnya tentang cara kerjanya, lihat [Domain Locator Across a Forest Trust](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) di Microsoft situs web.
![\[Nama default situs pertama\]](http://docs.aws.amazon.com/id_id/directoryservice/latest/admin-guide/images/default_first_site_name.png)
## Operasi tidak dapat dilakukan pada domain ini
Untuk mengatasi hal ini, pastikan kedua domain / direktori tidak memiliki nama NETBIOS yang tumpang tindih. Jika domain / direktori memiliki nama NETBIOS yang tumpang tindih, buat kembali salah satu dari mereka dengan nama NETBIOS yang berbeda, dan kemudian coba lagi.
## Pembuatan kepercayaan gagal karena kesalahan “Nama domain yang diperlukan dan valid”
Nama DNS hanya bisa berisi karakter abjad (A-Z), karakter numerik (0-9), tanda minus (-), dan titik (.). Karakter titik diperbolehkan hanya ketika mereka digunakan untuk membatasi komponen nama gaya domain. Juga, pertimbangkan hal berikut:
+ AWS Microsoft AD yang dikelola tidak mendukung kepercayaan dengan domain label tunggal. Untuk informasi selengkapnya, lihat [Microsoftdukungan untuk Domain Label Tunggal](https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/single-label-domains-support-policy).
+ Menurut RFC 1123 ([https://tools.ietf.org/html/rfc1123](https://tools.ietf.org/html/rfc1123)), satu-satunya karakter yang dapat digunakan dalam label DNS adalah “A” hingga “Z”, “a” hingga “z”, “0" hingga “9", dan tanda hubung (“-”). Titik [.] juga digunakan dalam nama DNS, tetapi hanya antara label DNS dan pada akhir dari FQDN.
+ Menurut RFC 952 ([https://tools.ietf.org/html/rfc952](https://tools.ietf.org/html/rfc952)), “nama” (Net, Host, Gateway, atau nama Domain) adalah string teks hingga 24 karakter yang diambil dari alfabet (A-Z), digit (0-9), tanda minus (-), dan titik (.). Perhatikan bahwa titik hanya diperbolehkan ketika berfungsi untuk membatasi komponen “nama gaya domain”.
Untuk informasi selengkapnya, lihat [Mematuhi Pembatasan Nama untuk Host dan Domain di Microsoft situs web](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959336(v=technet.10)).
## Alat umum untuk menguji kepercayaan
Berikut ini adalah alat yang dapat digunakan untuk memecahkan berbagai masalah terkait kepercayaan.
**AWS Alat pemecahan masalah Otomasi Systems Manager**
[Support Automation Workflows (SAW)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-support.html) memanfaatkan AWS Systems Manager Automation untuk memberi Anda runbook yang telah ditentukan sebelumnya. Directory Service Alat [AWSSupport-TroubleshootDirectoryTrust](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awssupport-troubleshootdirectorytrust.html)runbook membantu Anda mendiagnosis masalah pembuatan kepercayaan umum antara Microsoft AD yang AWS Dikelola dan Direktori Microsoft Aktif lokal.
**DirectoryServicePortTest alat**
Alat [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip)pengujian dapat membantu saat memecahkan masalah pembuatan kepercayaan antara AWS Microsoft AD yang Dikelola dan Direktori Aktif lokal. Sebagai contoh tentang bagaimana alat dapat digunakan, lihat [Uji AD Connector Anda](ad_connector_getting_started.md#connect_verification).
**Alat NETDOM dan NLTEST**
Administrator dapat menggunakan alat baris perintah **Netdom** dan **Nltest** untuk menemukan, menampilkan, membuat, menghapus, dan mengelola kepercayaan. Alat-alat ini berkomunikasi secara langsung dengan otoritas LSA pada pengendali domain. Untuk contoh tentang cara menggunakan alat ini, lihat [Netdom](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11)) dan [NLTEST](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11)) di situs web. Microsoft
**Alat penangkap paket**
Anda dapat menggunakan utilitas pengambilan paket Windows bawaan untuk menyelidiki dan memecahkan masalah jaringan potensial. Untuk informasi selengkapnya, lihat [Mengambil Jejak Jaringan tanpa menginstal apa pun](https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503).
# Pemecahan Masalah AWS Pemanfaatan CPU tinggi Microsoft AD yang Dikelola
Berikut ini dapat membantu Anda memecahkan masalah CPU tinggi pada pengontrol domain AWS Microsoft AD Terkelola.
## Menemukan akar penyebabnya
Langkah pertama dalam memecahkan masalah pemanfaatan CPU yang tinggi adalah menganalisis CloudWatch metrik untuk mengidentifikasi pola yang dapat menjelaskan peningkatan konsumsi sumber daya.
### Langkah 1: Tinjau Directory Service CloudWatch metrik
Pantau performa Microsoft AD yang AWS Dikelola menggunakan CloudWatch metrik untuk mengidentifikasi pola lalu lintas yang berkorelasi dengan penggunaan CPU yang tinggi. Untuk informasi rinci tentang melihat dan menafsirkan Directory Service metrik, lihat. [Menggunakan CloudWatch untuk memantau kinerja pengontrol domain Microsoft AD yang AWS Dikelola](ms_ad_monitor_dc_performance.md)
Cari pola pergeseran dalam metrik kunci berikut yang mungkin menjelaskan peningkatan CPU:
+ **Kueri DNS per detik** — Lonjakan mendadak dapat mengindikasikan masalah resolusi DNS atau aplikasi yang salah dikonfigurasi.
+ Otentikasi **KerberOS/NTLM — Tingkat otentikasi yang** lebih tinggi dari login pengguna atau akun layanan.
+ **Kueri LDAP per detik** — Peningkatan lalu lintas LDAP dari aplikasi atau layanan.
Bandingkan metrik saat ini dengan garis dasar historis untuk mengidentifikasi kapan pemanfaatan CPU yang tinggi dimulai dan menghubungkannya dengan peningkatan lalu lintas tertentu. Jika tidak ada korelasi yang ditemukan dalam metrik maka akar penyebabnya bukanlah peningkatan lalu lintas yang luar biasa. Alih-alih akar penyebabnya kemungkinan adalah kueri LDAP yang tidak efisien, lewati ke. [Langkah 3: Tangkap analisis lalu lintas terperinci dengan Traffic Mirroring](#ms_ad_high_cpu_step3)
### Langkah 2: Identifikasi mesin sumber menggunakan VPC Flow Logs
VPC Flow Logs menyediakan metode yang efektif untuk mengidentifikasi alamat IP sumber mesin yang menghasilkan lalu lintas ke pengontrol domain Anda. Untuk informasi selengkapnya, lihat [Mencatat lalu lintas IP menggunakan Log Aliran VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html). Gunakan nomor port tujuan untuk membedakan antara layanan:
+ **Port 53** - Kueri DNS
+ **Port 88** — Otentikasi Kerberos
+ **Port 123** - Sinkronisasi jam NTP
+ **Pelabuhan 135, 49152-65535** — RPC
+ **Port 389, 636, 3268, 3269 - kueri LDAP (389 atau 3268** untuk LDAP standar, 636 atau 3269 untuk LDAPS)
+ **Port 445** - Berbagi file SMB (Kebijakan Grup)
+ **Port 464 — Perubahan** kata sandi Kerberos
+ **Port 9389 — Layanan Web** Direktori Aktif
Untuk mengaktifkan dan menganalisis Log Aliran VPC:
+ Aktifkan Log Aliran VPC untuk subnet yang berisi pengontrol domain Anda. ENIs
+ Filter log berdasarkan port tujuan untuk mengidentifikasi pola lalu lintas.
+ Atur oleh sebagian and/or besar paket sebagian besar byte selama periode waktu.
+ Analisis alamat IP sumber untuk menentukan mesin mana yang menghasilkan lalu lintas terbanyak.
### Langkah 3: Tangkap analisis lalu lintas terperinci dengan Traffic Mirroring
VPC Flow Logs memberikan informasi terbatas tentang konten permintaan yang sebenarnya. Untuk analisis yang lebih rinci, pertimbangkan Traffic Mirroring untuk menangkap data paket lengkap. Untuk informasi selengkapnya, lihat [Memulai menggunakan Pencerminan Lalu Lintas untuk memantau lalu lintas jaringan](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-getting-started.html). Ini sangat berguna ketika Anda perlu menganalisis:
+ Kompleksitas dan efisiensi filter LDAP
+ Pola kueri DNS tertentu
+ Detail permintaan otentikasi
Traffic Mirroring memungkinkan Anda untuk menangkap paket jaringan lengkap yang dikirim ke instance pengontrol domain Anda, memungkinkan analisis mendalam tentang lalu lintas yang menyebabkan pemanfaatan CPU tinggi.
### Langkah 4: Selidiki aplikasi sumber dan optimalkan lalu lintas
Setelah Anda mengidentifikasi mesin sumber dan pola lalu lintas, selidiki aplikasi yang menghasilkan lalu lintas:
+ **Tinjau konfigurasi aplikasi** — Periksa apakah aplikasi membuat kueri yang tidak efisien atau permintaan yang berlebihan. Hindari hard coding aplikasi ke pengontrol domain tunggal.
+ **Analisis kueri LDAP - Kueri** LDAP yang tidak efisien adalah penyebab paling umum dari CPU pengontrol domain tinggi. Cari filter kompleks yang bisa mendapatkan keuntungan dari pengindeksan atribut.
+ **Periksa cache DNS — Verifikasi bahwa caching** klien DNS diaktifkan untuk mengurangi kueri berulang.
+ **Periksa pola otentikasi** — Identifikasi apakah akun layanan terlalu sering mengautentikasi.
## Strategi resolusi
Berdasarkan penyelidikan Anda, terapkan strategi pengoptimalan yang tepat:
### Optimalkan aplikasi
+ **Optimalkan kueri LDAP — Tulis ulang kueri** LDAP yang kompleks. Hindari pengaturan basis pencarian ke root domain dan sebagai gantinya konfigurasikan ke OU di mana objek yang Anda cari berada. Hindari menggunakan lingkup pencarian yang melakukan pencarian subtree. Alih-alih menggunakan basis atau lingkup tingkat tunggal. Sertakan kelas objek dalam filter Anda. Misalnya, `(objectClass=user)` atau `(objectClass=computer)`. Hindari menggunakan wildcard di filter kecuali atribut diindeks. Tambahkan indeks jika pemindaian wildcard diperlukan. Untuk informasi selengkapnya, lihat [Perluas skema AD Microsoft AWS Terkelola Anda](ms_ad_schema_extensions.md). Jangan mengindeks semuanya karena proses pengindeksan juga meningkatkan pemanfaatan CPU.
```
# Sample LDIF code to index the email attribute
dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com
changetype: modify
replace: searchFlags
searchFlags: 1
```
+ **Aktifkan cache klien DNS** — Konfigurasikan klien untuk menyimpan respons DNS secara lokal untuk mengurangi beban server.
+ **Implementasikan penyatuan koneksi** — Konfigurasikan aplikasi untuk menggunakan kembali koneksi LDAP daripada membuat yang baru untuk setiap kueri.
### Skalakan infrastruktur direktori Anda
Jika optimasi lalu lintas tidak menyelesaikan pemanfaatan CPU yang tinggi:
+ **Tambahkan lebih banyak pengontrol domain** — Skalakan dengan menggunakan pengontrol domain tambahan untuk mendistribusikan beban. Untuk informasi selengkapnya, lihat [Menerapkan pengontrol domain tambahan untuk AWS Microsoft AD yang Dikelola](ms_ad_deploy_additional_dcs.md).
+ **Tingkatkan ke Enterprise Edition** - Jika menggunakan Edisi Standar, tingkatkan ke Enterprise Edition untuk meningkatkan kapasitas dan kinerja CPU. Untuk informasi selengkapnya, lihat [Memutakhirkan Microsoft AD yang AWS Dikelola](ms_ad_upgrade_edition.md). Jika sudah menggunakan Enterprise Edition, Hubungi [AWS Dukungan](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html)untuk peningkatan kapasitas.
Untuk informasi harga tentang edisi Microsoft AD AWS Terkelola, lihat [Directory Service Harga](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).