各位好
我在更改使用者密碼的時候
希望可以個別捕捉舊密碼錯誤和不符合密碼原則這兩個例外
測試下來的結果
這兩種情況都會進到PasswordException裡面
想問一下除了用contains的方式判斷錯誤訊息外
有沒有更快或更好的方式可以單獨處理這兩個例外呢?
public void SetPassword(string pUsername)
{
try
{
string strOldPassword = "Aa123456";
string strNewPassword = "Bb123456";
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "127.0.0.1"))
{
UserPrincipal user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, pUsername);
if (user != null)
{
user.ChangePassword(strOldPassword, strNewPassword);
user.Save();
}
}
}
catch (PasswordException ex)
{
if (ex.Message.Contains("密碼錯誤"))
{
//do something...
}
else if (ex.Message.Contains("密碼原則錯誤"))
{
//do something...
}
else
{
throw ex;
}
}
}
可以試試PrincipalContext類別的ValidateCredentials方法
https://learn.microsoft.com/zh-tw/dotnet/api/system.directoryservices.accountmanagement.principalcontext?view=dotnet-plat-ext-8.0
就不用contains了
但不符合密碼原則,應該還是只能利用 PasswordException 去處理了
我有查到這個方法~
但這個方法是不是就是單純檢查是否可以登入而已?
因為我發現如果那個使用者的密碼已到期的話
好像也是會回傳false
我原本想做的是
使用者先輸入原本帳號密碼
若帳號密碼正確才判斷密碼是否到期
如果到期再讓使用者更改密碼
但由於ValidateCredentials這個方法只要密碼到期
都會回傳false
我就無法實現先檢查原本帳號密碼是否正確這一步
最後我才會想說用UserPrincipal類別的ChangePassword方法
將兩個輸入值都設定為使用者原本的密碼
若出現密碼原則錯誤
則代表原密碼是正確的
若出現密碼錯誤
那就代表使用者輸入的密碼是錯的
試試這個屬性PasswordExpirationDate
DateTime eDate = user.PasswordExpirationDate;
這個屬性可以成功檢查到期日~
但有我個問題
我發現他只需要使用者名稱就可以看到到期日
不需要驗證密碼耶
那如同我前面說的已到期的使用者
有什麼方法可以驗證目前帳號密碼是否正確嗎?
只要是超過到期日,仍有沒有變更密碼的,原密碼不就是失效的嗎?
就算是原密碼是正確的,去做ValidateCredentials,還是會回傳false
是這樣沒錯
但我希望的是使用者可以登入後再去改密碼
因為我目前想不到有什麼方法可以同時驗證使用者登入資訊
又可以讓他改密碼的方法
已到期的帳號判斷為無效很正常
而且先得到資訊(到期日)再判斷處理(更改密碼)也比較省資源不是嗎?
不清楚你流程這樣設計的原因
個人淺見如下,請各位前輩指點。
判斷密碼是否到期
1.已到期-->變更密碼
2.未到期
2.1檢查舊密碼(ValidateCredentials)
2.1.1 true-->變更密碼
2.1.2 false-->重新輸入密碼-->2.1檢查舊密碼
這要歸功於我們公司奇怪的流程設計XD
因為現階段沒有一個地方是可以讓使用者改密碼的
再加上很多系統又是跟AD帳號串接
一旦密碼到期後所有系統就會無法登入
如果寫一支工具讓使用者改密碼
又會出現無法確認改密碼的是不是本人的問題
(怕有人亂改其他人的密碼)
因此才會出現以上奇怪的設計
要在檢查舊密碼成功的情況下
才能讓使用者變更密碼
你們是不是很多同仁都沒進公司?
不然如果過期,遇到的第一個狀況就是無法登入電腦
有一部份是沒進公司
但有一些是作業員沒個人電腦
他們都是用共用電腦登系統的
所以他們只會反饋帳號無法登入的問題給我們
我目前是這樣做:寫一支程式,去檢查密碼到期日小於3天的帳號,寄通知信給user,密碼即將到期,請他們記得改密碼。
理解了
我覺得只能落實共用電腦也要使用自己的AD登入電腦再進系統
如果程式下手,程式方面因為當初設計就不是給這樣流程使用的,不然就是自己override,先建一個自己的驗證DB,確認是本人再給改密碼
寄通知信給user,請他們記得改密碼,這個其實作用不大
因為這情境很多是工廠人員,他們其實不需要天天看電腦,只有被告知要去簽核或其他作業時才會去操作電腦,可能一個月才會使用電腦一次
寄信給使用者這個我有考慮過
但就像 厚厚 說的一樣
作業員不會天天去看電腦,自然也不會有收信的習慣
他們大部分的訊息都自來自於主管的通知
驗證的DB我也有想過
但如果要驗證的話勢必要存使用者密碼
這個又有資安疑慮怕會衍生其他問題XD
用個人AD帳號登入電腦的部分
我覺得要改成這個模式有難度QQ
畢竟很多程式、檔案路徑位置都是固定的
登個人帳號就又要重新安裝或調整
不管是作業員或主管的接受度應該都不高
可能會需要時間去溝通和討論