Akhir tahun, semua orang perlahan-lahan mengambil stok.

Bagi saya, tahun ini dikenang oleh proyek implementasi Single Sign On (SSO) antara SAP dan Windows. Dalam artikel ini saya akan menceritakan tentang pengalaman implementasi dan manajemen proyek, jebakan, temuan dan kesimpulan.

Perusahaan ini adalah perusahaan transportasi besar di Belgia, menggabungkan metro, trem, dan bus. Ada lebih dari 10 ribu karyawan, yang hampir dua ribu adalah backoffice, menggunakan banyak alat: situs web perusahaan, surat, layanan aplikasi, sharepoint, arsiparis dan, tentu saja, SAP.

SAP ada di mana-mana: dari pembukuan dan SDM hingga pendaftaran pergerakan unit transportasi, dokumentasi kecelakaan, analisis, pengadaan, pergudangan, dll.

Masalah:

• SAP untuk pengguna PC adalah aplikasi terpisah yang memerlukan kata sandi Anda untuk memasukkan
• Pertama, Anda perlu meminta kata sandi, dan kemudian ingat. Dukungan teknis dipaksa untuk menerima panggilan untuk membuat dan mengubah kata sandi.
• Dari sudut pandang pengguna, kata sandi tambahan adalah masalah tambahan. Orang menyimpan kata sandi di atas kertas atau membuatnya terlalu sederhana. Keamanan berteriak tentang pelanggaran berat.
• Persyaratan minimum untuk kata sandi untuk PC tidak cocok dengan pengaturan kata sandi di SAP. Jika Anda membawanya ke common denominator, lebih baik segera menerapkan SSO.

Tujuan: mengimplementasikan SSO antara Windows dan SAP, sehingga saat masuk ke akun PC Anda, pengguna dapat masuk ke SAP tanpa memasukkan kata sandi.

Jika Anda tidak berurusan dengan SAP, Anda akan tertarik pada artikel ini dari sudut pandang manajemen proyek, karena sappers dari rincian tersebut akan diberikan (dalam kurung).

Di bawah potongan:

1. Lingkup
   1.1 Ruang Lingkup Orang
   1.2 Sistem cakupan
2. Komponen
   2.1 Mengubah parameter sistem
   2.2 Windows Active Directory (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Mengikat Pengguna SAP ke AD-nya
   2.5 Memodifikasi file SAP logon.ini
3. Pengujian
4. SNC adalah lubang keamanan
5. Kerja tim
6. Informasi Bisnis
7. Kesulitan terjemahan
8. Ringkasan dan Kesimpulan

Pendahuluan

Ke depan, jika Anda tidak ingin mengisi kerucut standar, berikut adalah daftar pertanyaan yang harus Anda perjelas sendiri di awal proyek:

• Lingkup proyek (Sistem, pengguna - dalam urutan apa yang kami laksanakan, di mana prioritas dan apa yang dapat dibuang jika ada masalah, yang harus diakses pengguna, dll.)
• Departemen utama yang terkena dampak proyek (Sekalipun proyek itu bersinggungan, tetap penting bahwa semua orang sudah diberitahu sebelumnya)
• Kekuatan Anda (Tidak mudah untuk melarikan diri di sini - di perusahaan Eropa semuanya didasarkan pada persetujuan dan keinginan sukarela untuk membantu. Jika departemen mengatakan bahwa mereka tidak memiliki sumber daya, maka hampir tidak mungkin untuk menekan dan “memaksa”. Tetapi Anda dapat menghubungi konsultan eksternal untuk bantuan, misalnya)
• Pengaturan waktu (Untuk keseluruhan proyek secara keseluruhan dan untuk bagian tertentu)
• Prosedur persetujuan (peraturan birokrasi - di perusahaan besar ini bukan pertanyaan terakhir)
• Kemungkinan kesulitan (Semua. Kemungkinan. Kesulitan.)

Kami telah mengubah keanggotaan proyek beberapa kali: pada awalnya hanya departemen otorisasi di SAP dan departemen administrator (Komponen Dasar). Kemudian mereka bergabung dengan departemen yang berurusan dengan otorisasi di Windows (Active Directory, AD) dan departemen implementasi pembaruan (Pengemasan), kemudian departemen basis data dan departemen aplikasi mobile, dll.

Seorang konsultan eksternal diundang untuk sisi teknis dari masalah ini, dan Manajer Proyek (PM) menjadi saya, sebagai orang yang terlibat dalam otorisasi dalam SAP (oleh karena itu, akan ada lebih banyak detail mengenai otorisasi dalam SAP dalam artikel ini daripada yang lain).

Klarifikasi penting: semua akses yang kami berikan di SAP disesuaikan. Kami tidak menggunakan peran standar yang ditawarkan sistem, tetapi membuat peran baru, berdasarkan departemen, berdasarkan posisi, berdasarkan fungsi. Sampai saat ini, kami tidak memiliki sinkronisasi antara pengguna SAP dan Windows AD. Misalnya, jika pengguna Anda memiliki hak administrator di jaringan lokal, ini tidak berarti bahwa ia juga seorang administrator di SAP.

1. Lingkup

1.1 Ruang Lingkup Orang

Orang-orang di perusahaan kami menggunakan SAP melalui aplikasi pada komputer pribadi (thin client - SAP Logon GUI), tetapi tidak hanya. Bagaimana cara menghitung pengguna yang berada di bawah distribusi?

Kami menganggap semua orang yang terhubung setiap hari melalui SAP Logon (Dialog tipe pengguna SAP) dari laptop. Dalam kategori ini, seluruh kantor pusat - staf administrasi, bukh, Ichar, pengembang, penguji, logistik, dll.

Dikecualikan:

• mereka yang memiliki komputer desktop, bukan laptop
• 8 ribu pengguna yang tidak pernah membuka logon SAP, tetapi menggunakan SAP melalui situs web dan aplikasi (SAP tipe pengguna Komunikasi)
• semua pengguna eksternal (bukan karyawan, tetapi harus masuk ke sistem melalui VPN)

1.2 Sistem Lingkup

Di perusahaan kami, SAP menggunakan enam lanskap aktif ( ECC, BI, SRM, Netweaver, PI, Solution manager ), tidak termasuk kotak pasir. Masing-masing dari mereka memiliki DEV , ACC , PRD - i.e. sebenarnya, itu adalah 6 * 3 = 18 sistem.

Dengan pemungutan suara vokal, diputuskan untuk mengambil hanya empat bentang alam pertama. PI dan SM digunakan oleh lingkaran administrator yang sempit dan memerlukan pembaruan sistem itu sendiri (setidaknya memperbarui komponen SAP_BASIS ke versi 740). Kalau tidak, transaksi sncwizard tidak didukung, dan melakukan ini secara manual terlalu merepotkan untuk 10-20 orang.

2. Komponen

Orang yang tertarik pada perincian itu akan menemukan petunjuk langkah demi langkah di situs web SAP , serta berbagai metode yang tersedia (kami memilih SSO berdasarkan Kerberos , tetapi ini tidak selalu merupakan opsi yang jelas).

Dari sudut pandang yang sangat disederhanakan (milik saya), SSO adalah add-on di SAP yang memungkinkan Anda untuk masuk menggunakan akun Windows Anda. Anda menyalakan komputer, memasukkan kata sandi, dan untuk masuk ke SAP Anda hanya perlu mengklik dua kali.

Agar sihir berfungsi, Anda membutuhkan 5 komponen:

2.1 Mengubah parameter sistem (instance SAP)

Dalam sistem SAP ( ECC , BI , SRM , Netweaver ) Anda perlu mengaktifkan parameter snc / enable = 1. Ini dilakukan melalui sncwizard dan termasuk persiapan, reboot sistem dan langkah-langkah aktivasi akhir.

Kami menemukan parameter sebelum dan sesudahnya dengan bantuan konsultan tersebut, bantuan dari departemen lain dan coba-coba. Yang paling sulit di sini adalah me-restart sistem.

Selalu sulit untuk memulai kembali PRD dalam produksi, pekerjaan terus berlangsung sepanjang waktu. Dan di sebuah perusahaan transportasi, ini menjadi lebih rumit: transportasi bergerak dari jam lima pagi sampai satu pagi, bahkan pada akhir pekan. Setiap kesulitan dengan PRD mempengaruhi tidak hanya karyawan perusahaan, tetapi seluruh kota dan puluhan ribu orang. Dengan kata lain - Anda perlu meminimalkan waktu ketika sistem tidak tersedia dan, jika mungkin, gabungkan dengan pembaruan lainnya. Pada saat yang sama, birokrasi tidak boleh diremehkan: restart adalah tanggal, waktu, durasi (jika parameter tidak disimpan pertama kali) dan pemberitahuan bisnis.

Kami memiliki empat sistem SAP PRD: ECC, Netweaver, SRM, BI - untuk mem-boot ulang

ECC adalah yang paling penting, semua data real-time dan transportasi utama terkait dengannya: bus, trem.

Data dari sistem Netweaver (kecelakaan, aplikasi mobile), serta sistem ECC, digunakan bahkan pada jam 3 pagi - jika trem tidak pergi, maka kru perbaikan pergi.

Sistem SRM - terutama digunakan untuk pengadaan dan tersedia setiap hari setelah pukul 18:00.

Dengan BI, kesulitannya adalah bahwa pada akhir pekan arus data dari ECC menuju sistem, di samping itu, kadang-kadang laporan dari BI digunakan oleh manajemen puncak di luar jam kerja.

Secara total, butuh 2 minggu untuk me-reboot semua PRD.
Restart PS dari masing-masing sistem PRD didahului oleh restart semua DEV dan ACC, yang lebih mudah untuk dikoordinasikan, tetapi juga memerlukan perencanaan.

2.2 Windows Active Directory (AD)

Active Directory membutuhkan pembuatan pengguna teknis khusus (SAP Kerberos). Pengguna ini akan menghubungi Windows untuk mendapatkan salinan tiket input untuk SAP. Satu pengguna layanan AD semacam itu sudah cukup untuk semua sistem SAP.

Bagian ini sepenuhnya dibuat oleh konsultan eksternal kami dan tim Direktori Aktif, termasuk beberapa iterasi untuk memperbaiki parameter dan mengkonfigurasi perpustakaan khusus, tetapi bagi saya itu tetap lebih dari "kotak hitam".

2.3 Menginstal SAP Secure Login Client (SLC) di komputer pengguna

Program ini dengan sendirinya tidak melakukan apa pun. Anda memerlukannya untuk menyimpan tiket dari AD yang mengkonfirmasi pengguna Anda saat masuk ke sesi Windows, dan jika perlu, kirimkan tiket ini ke SAP untuk otorisasi. SLC dapat diinstal untuk semua pengguna segera di awal proyek - tanpa komponen SSO lainnya, itu tidak akan berhasil.

2.4 Mengikat pengguna SAP ke pengguna AD-nya

Seperti yang telah disebutkan, di perusahaan kami tidak ada manajemen pengguna tunggal, akses ke berbagai sistem diperoleh dari tim yang berbeda. Dalam hal ini, login pengguna di SAP berbeda dari nama pengguna di Windows, misalnya, pengguna # 45011 dalam AD adalah Ivan Ivanov atau IVANOVI . Kumpulan inilah yang perlu diisi SNC (melalui transaksi SU01, bidang SNC, p: CN = ADname @ domain).

Perusahaan kami tidak memiliki SAP Identity Management. Oleh karena itu, perlu untuk menyelesaikan dua masalah: membuat pengguna baru dan memperbarui parameter yang sudah ada.

Buat pengguna baru
Dalam sistem utama (ECC) setiap hari kerja 4-6 login baru dibuat, ini hampir 1000 pengguna baru per tahun. Prosesnya otomatis: saat membuat pengguna, program mengisi alamat, nama, pengaturan dasar. Kami memutuskan bahwa program juga harus mengisi bidang SNC pada tahap pembuatan pengguna, terlepas dari apakah orang tersebut akan membutuhkan SSO di SAP setelahnya atau tidak.

Tangkapannya adalah bahwa untuk setiap pengguna Anda perlu mengisi nama sendiri yang unik di AD, mis. ini bukan parameter yang sama untuk semua orang - mis. perlu bahwa program itu sendiri mencari nama pengguna dalam AD dan mengisinya dengan SAP.

Pengembang dengan cepat memperbarui program. Kode dan pengujian dasar memakan waktu 2 hari, tetapi data untuk verifikasi dalam ACC tidak cocok untuk kami (AD tidak diperbarui), jadi kami segera mengirim perubahan ke PRD. Ternyata semuanya lebih rumit dari yang kita duga. Dalam perjalanan investigasi, kami sampai pada skema berikut:

1. Pertama, pengguna dibuat dalam sistem SDM (di SAP mereka dapat dilihat di PA20 )
2. Kemudian mereka disalin ke tabel-Z, bersama dengan data tentang departemen, posisi, posisi, apakah itu tautan utama, dll.
3. Kemudian data pengguna dikirim ke AD dan di sini sistem membuat pengguna di Windows, dan memberinya nama dalam AD dan surat
4. Alur PI dalam diagram ini hanya untuk memahami bahwa ini adalah proses pihak ketiga dari sistem ketiga
5. Data disalin kembali ke SAP (dalam tabel-Z baru), kali ini hanya nama AD dan alamat surat
6. Pada tahap terakhir, Z-program diluncurkan, yang menciptakan pengguna di SAP ( SU01 ). Tidak semua pengguna yang dibuat dalam sistem SDM akan dibuat nanti di SAP, ada banyak yang pada akhirnya tidak menggunakan SAP

Butuh hampir dua minggu untuk mencari, mengoordinasikan perubahan, menyepakati jadwal untuk memperbarui dan memuat / menurunkan tabel. Itu masalah sinkronisasi - program pembuatan pengguna (poin 6) harus benar-benar diluncurkan setelah semua program lain sudah bekerja dan data disalin ke tabel. Sebagai hasilnya, kami melacak selama dua minggu ketika program mana yang berakhir dan pada jam berapa, dan mendebat skema tersebut.

Saat pengguna dibuat dengan bidang SNC yang diisi, tetapi tanpa nama AD yang diperlukan, di SU01 Anda dapat melihat semua rekan pengguna yang disayangkan diikat ke satu, pengguna AD yang tidak ada.

Memperbarui pengaturan pengguna yang ada
Justru karena login SAP kami dan Windows tidak cocok, kami tidak dapat menggunakan solusi SAP standar untuk pengisian massal di bidang SNC ( RSUSR300 via program SNC1 ).

Akibatnya, saya memperbarui data 10 ribu pengguna yang ada menggunakan skrip darurat ( SAP eCATT ), mengunggah data pengguna secara manual dan membuat varian. Agar berhasil, saya harus membuka diri untuk mengubah sistem eCATT di PRD dan ACC dan menjanjikan pengembang jutaan cookie.

2.5 Memodifikasi file SAP logon.ini

Secara teknis, ini 1 menit. Hanya perlu dicatat di properti file bahwa koneksi melalui SNC tersedia .

Kesulitannya adalah bahwa file ini terletak secara lokal di PC pengguna dan dua ribu pengguna perlu mengubahnya.

Bahkan, bagi kami, implementasi terakhir adalah saat mendistribusikan file sap.logon.ini baru di antara pengguna, daripada mengubah parameter PRD. Karena bahkan jika empat komponen pertama sudah dilakukan, dan kelima terakhir tidak, maka sihir tidak akan terjadi.

Dengan paragraf terakhir muncul insiden kecil. Saya melaporkan kepada manajemen bahwa kami memiliki 2.000 pengguna yang akan menginstal pembaruan, dan ketika tiba saatnya untuk mengimplementasikannya, mereka mengirim saya status di mana ada 3.500 dari mereka. Saya merasa tidak enak. Itu karena untuk bagian saya, saya hanya melihat pengguna SAP aktif, tetapi dalam kenyataannya pembaruan dikirim ke semua laptop pribadi, yang jauh lebih banyak di perusahaan. Terima kasih Tuhan, tidak ada bug teknis yang muncul.

3. Pengujian

Bagaimana cara menguji SSO? Entah itu berhasil atau tidak. Pengembang kami mendengus dan berkata bahwa Anda tidak perlu menguji apa pun, dan begitu semuanya bekerja di kotak pasir, Anda harus mengirimkannya ke produksi. Tentu saja Tidak ada yang akan mengatakan dia menulis kode dengan bug.

Anda perlu memeriksa:

• Apakah login SAP berfungsi dengan SSO setelah reboot
• dapatkah pengguna menggunakan SSO saat terhubung dengan VPN
• kesulitan bagi pengembang untuk sistem lain untuk memodifikasi logon SAP

SSO bukan program, sulit untuk mengimplementasikannya secara konsisten DEV - ACC - PRD. Namun demikian, pengujian awal diperlukan untuk menangkap semua yang berpotensi salah. Pengujian dalam hal ini adalah distribusi SAP logon.ini baru ketika semua komponen sudah berjalan. Kami menguji DEV dan ACC dengan pengembang dan SAP logon.ini baru dengan PRD dengan pilihan pengguna bisnis.

Apa yang mereka temukan:

• terkadang (1 kasing per 500) Anda perlu menginstal ulang SAP logon atau SLC sepenuhnya
• pengguna kunci yang memiliki hak untuk mengubah pengguna lain (lebih lanjut tentang itu di paragraf berikutnya)

4. SNC adalah lubang keamanan

Bagaimana dengan memodifikasi bidang SNC?
Faktanya adalah bahwa dengan mengubah bidang SNC dari pengguna lain (dalam SU01) ke milik Anda, Anda dapat terhubung di bawah akun orang lain bahkan tanpa mengubah kata sandi. Sistem hanya akan menanyakan kepada Anda pengguna mana yang harus dipilih, milik Anda atau milik orang lain. Namun, jika Anda melakukan ini, besok tidak ada yang akan melihat apa pun, karena kata sandi tetap tidak berubah.

Di perusahaan mana pun ada orang yang terlibat dalam manajemen pengguna . Biasanya, orang-orang ini memantau pembuatan pengguna ( SU01 ) dan akses untuk mereka ( PFCG ), serta pembaruan kata sandi. Adalah logis bahwa mereka juga dapat mengisi bidang SNC .

Masalah muncul ketika perusahaan perlu memisahkan manajemen pengguna dan hanya pengguna kunci. Administrator membuat pengguna, dan pengguna utama, jika perlu, mengubah data mereka: parameter pengguna, bahasanya, lokasinya, dll.

Di SAP, tidak ada langkah kontrol terpisah untuk mengubah bidang SNC. Setiap orang yang memiliki hak untuk mengubah pengguna (objek S_USER_GRP, ACTVT 02 ) juga dapat mengubah bidang SNC (sedangkan mengubah kata sandi membutuhkan objek yang sama, tetapi dengan ACTVT 05 ).

Mungkin ada beberapa solusi:

• mengambil hak akses ke SU01 dari pengguna utama, dan sebagai tanggapan berikan semua orang SU2 dan SU3, di mana pengguna dapat mengubah parameter mereka sendiri
• mengambil hak akses ke SU01, dan sebagai gantinya memberikan z-transaksi di mana tab SNC tidak akan ditampilkan
• tinggalkan SU01, tetapi lindungi bidang SNC dengan kontrol khusus

Akibatnya, kami memilih opsi yang terakhir dengan membuat objek otorisasi khusus dan mengikat program SU01 di atasnya. Namun, ternyata kemudian, SAP memiliki solusi yang serupa - Anda dapat mengaktifkan pemeliharaan yang diperluas ( catatan 1882254 ) untuk masing-masing bidang SU01.

5. Kerja tim

Selama proyek, saya menghadapi semua kesulitan kerja tim dan menemukan banyak kebenaran dasar:

• Tidak pernah ada banyak waktu . Batas waktu adalah yang terbaik yang dapat disediakan PM.
• Seharusnya ada rencana proyek dasar , tetapi perlu ditinjau setiap minggu, meninggalkan margin besar untuk fleksibilitas. Di suatu tempat kami bergerak lebih cepat, di suatu tempat diinjak-injak.
• Paman orang dewasa di departemen TI kadang-kadang tidak berbeda dalam perilaku dari anak perempuan dalam akuntansi : mereka menolak untuk bekerja satu sama lain, hanya karena mereka tidak menyukai orang tersebut. Dan sekali lagi perlu untuk menyelesaikan masalah subordinasi.
• Seringkali departemen menghambat persetujuan proyek , karena tidak jelas siapa yang bertanggung jawab atas implementasi dan siapa yang jam anggaran tambahannya jatuh. Penting untuk membiarkan manajer mendiskusikan semuanya secara langsung.
• Situasi tak terduga muncul sesekali . Yang terbaik yang dapat dilakukan adalah komunikasi tepat waktu, surat, panggilan, SMS ke semua orang yang terlibat.
• Tidak ada yang lebih baik dari pertemuan pribadi . Pertanyaan dipecahkan berkali-kali lebih cepat daripada saat dibahas melalui surat. Di sisi lain, semua pengaturan pribadi harus segera diikuti oleh surat berikutnya (untuk memperbaiki dan tidak melupakan)
• PM dalam proyek TI hanya bisa mempercayai orang . Bahkan, Anda tidak tahu berapa banyak waktu yang diperlukan untuk tindakan ini atau itu: misalnya, membuat pengguna dalam AD untuk Kerberos, 10 menit atau tiga hari? Dan tidak ada cara untuk memeriksa apakah pengujian benar-benar berhenti atau seseorang bermain-main. Tetap hanya untuk percaya.

Selain itu, banyak tergantung pada ketekunan konsultan. Seseorang sendirian, atau konsultan pembangunan atau PM, harus sama kurang ajarnya dengan peluru dan meninju tembok birokrasi. Dalam hal ini, saya sebagian beruntung, konsultan yang kami undang menyebalkan dan terkadang tak tertahankan (sulit untuk membuatnya mendengar sesuatu), tetapi ia tahu bisnisnya: ia melaporkan masalah dan segera berhenti dan tidak tenang sampai masalah terselesaikan.

6. Informasi untuk bisnis

Di perusahaan besar, perubahan yang mempengaruhi pengguna akhir harus tepat waktu, dan diumumkan lebih baik sebelumnya.

Dalam kasus kami, penting untuk memberi tahu semua pengguna bahwa sekarang mereka tidak perlu kata sandi untuk masuk ke SAP. Selain itu, perlu untuk menyediakan dokumentasi teknis untuk saluran dukungan 1 dengan semua kemungkinan kesalahan yang mungkin timbul setelah implementasi.

Saya harus mengakui bahwa dengan komunikasi semua yang salah bisa terjadi.

Pertama , kami mengumumkan kepada pengguna tentang SSO di situs web perusahaan, dan bukan melalui surat. Seberapa sering Anda membaca situs web perusahaan? SAP .

- , , , , , , , ( - ?) , .

- , Go Live, , ( 2 ), . .

7. fuck-up

5- SSO SAP, , .

: . , — . . 2- , 500 -. .

. “use a default language SAP logon” — , , ( SU01 , Defaults ). « SAP» .

, -, .

- .

8.

SSO — , . , 1-2 , 3- .

. . , , , .

SSO , , , , . AD, SNC. , . , ( , ) — .

 ,     ,   . 

Padatan:

• Waktu utama dalam 3 bulan dihabiskan untuk koordinasi dan koordinasi tindakan
• Departemen yang terlibat dalam proyek ini mulai lebih memahami pekerjaan masing-masing.
• Selama pengujian, Anda harus memperkenalkan diri sebagai pengganti pengguna akhir - jadi Anda ingin melihat di pesan informasi, dan di pengaturan dasar.
• SSO untuk SAP diterapkan. Pengguna senang dan sudah lupa tentang waktu ketika Anda harus mengingat kata sandi dari SAP. Hubungi dukungan teknis lebih jarang, tepuk tangan.