2010-10-12 31 views
20

Tôi có một tập lệnh Powershell sẽ được chạy thông qua một công cụ tự động hóa đối với nhiều máy chủ. Nó hoạt động tốt trên các máy Windows, vì các cuộc gọi từ xa sử dụng tài khoản dịch vụ của công cụ mà không cần phải nhắc hoặc phơi bày bất kỳ thông tin đăng nhập nào trong mã. Kịch bản này cũng chạy với các máy Linux thông qua SSH bằng gói SharpSSH. SharpSSH không tự động sử dụng thông tin đăng nhập của người dùng Powershell nhưng yêu cầu tên người dùng và mật khẩu, tệp khóa RSA hoặc đối tượng PSCredential. Tôi không thể nhắc thông tin đăng nhập bằng cách sử dụng Nhận-Credential vì nó được chạy qua công cụ tự động hóa. Tôi không muốn để lộ tên người dùng và mật khẩu trong mã hoặc có một khóa RSA ngồi ở đó. Tôi muốn xây dựng một đối tượng PSCredential từ người dùng Powershell hiện tại (tài khoản dịch vụ). Việc thử [System.Net.CredentialCache] :: DefaultNetworkCredentials cho thấy một khoảng trống và [System.Security.Principal.WindowsIdentity] :: GetCurrent() không cung cấp đối tượng hoặc thông tin mà tôi cần.Nhận đối tượng thông tin đăng nhập của người dùng hiện tại trong Powershell mà không cần nhắc

Có ai có phương pháp tạo đối tượng PSCredential từ người dùng hiện tại không? Hoặc có thể là một sự thay thế hoàn toàn khác cho vấn đề này?

Rất cám ơn!

Trả lời

14

API Windows sẽ không hiển thị thông tin bạn cần, đó là lý do Powershell không thể truy cập chúng. Một tính năng có chủ ý của hệ thống con bảo mật. Cách duy nhất để làm việc này là dành cho các máy Linux để tin tưởng vào máy gọi điện, chẳng hạn như kết nối chúng với Active Directory (hoặc bất kỳ thiết lập kerberos nào).

Ngoài ra, bạn cần phải lưu trữ và chuyển thông tin này bằng cách nào đó.

Bạn có thể lưu khóa RSA trong kho khóa của người dùng và giải nén nó tại thời gian chạy (sử dụng .NET Crypto/Keystore), do đó bạn không lưu trữ khóa chung với mã. Bằng cách đó, bản thân khóa sẽ được bảo vệ bởi hệ điều hành và chỉ có sẵn khi người dùng gọi điện được xác thực. Bạn sẽ có thêm một thứ để cài đặt, nhưng có thể là cách duy nhất để đạt được những gì bạn đang nhắm tới.

+1

Ahh, thật không may. Sau một số cuộc thảo luận và nghiên cứu, chúng ta sẽ đi với khóa RSA. Nó sẽ kết thúc cho phép nhiều hơn trong tương lai anyway. Cảm ơn, Taylor! – Beege

+0

Bạn nói nếu người dùng là một phần của AD, bạn có thể nhận được một đối tượng chứng chỉ; đúng không? Tôi đang cố gắng làm điều này (tiêu đề của câu hỏi), trên Windows. – ryanwebjackson

3

Vì bạn có thể nhận được mật khẩu trong văn bản thuần túy từ một đối tượng thông tin xác thực, tôi nghi ngờ bạn có thể nhận được điều này mà không cần nhắc.

3

Làm cách nào để mã hóa mật khẩu bằng khóa mã hóa của tài khoản dịch vụ?

Một ví dụ nhanh:

Run PowerShell như tài khoản dịch vụ, chạy sau và lưu kết quả vào một tập tin văn bản (hoặc nhúng nó trong cuộc gọi scheduled task):

$String = '<PASSWORD>' 
ConvertFrom-SecureString -SecureString (ConvertTo-SecureString -String $String -AsPlainText -Force) 

Sử dụng theo dõi trong công việc đã lập lịch của bạn để giải mã và sử dụng mật khẩu:

$EncryptedString = '<ENCRYPTED PASSWORD FROM ABOVE>' 
[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR((ConvertTo-SecureString -String $EncryptedString))) 

Điều đó sẽ làm điều đó. Bạn không thể sử dụng lại mật khẩu được mã hóa trên một máy tính khác, hoặc nếu bạn vì bất kỳ lý do gì phá hủy cửa hàng khóa địa phương của bạn :)

+0

Phương thức secureString có thể đảo ngược, vì vậy mật khẩu không an toàn về mặt kỹ thuật. Nếu không có tùy chọn -force bạn sẽ nhận được: "ConvertTo-SecureString: Hệ thống không thể bảo vệ đầu vào văn bản thuần túy". – cmcginty

Các vấn đề liên quan