網域DC時間錯誤造成client電腦時間也錯了

 一台虛擬機DC的時間被設定成與底層hyperv系統同步，結果與正確的時間差了一分多鐘。

PDC的時間是正確的，所以並不是所有client電腦的時間都錯了，就看是抓到哪台DC做時間同步。

時間錯誤的DC一開始就直接用NTPCLOCK這個小工具調整成對的時間，但沒多久又變回錯的時間，在該伺服器執行"w32tm /query /configuration"，有看到有一區"VMICTimeProvider"的設定，enable=1，這就是設定成與底層hyperv系統同步的地方。

直接找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider ，把enable改成0就好，不用重開機，然後在用NTPCLOCK調成正確時間就行了。

Client端如果不想等重開機做時間同步的話，可以下指令直接強制同步。

要用系統管理員執行cmd，然後輸入 w32tm /resync就可以開始同步了，時間不會馬上就變正確的，而且會慢慢的縮小與正確時間的差距，所以要等一下。

可以開啟client的時鐘，如果是client的時間是比較慢，就會發現秒數有時後會跳的比較快，然後慢慢跟上正確的時間。

Domain Controller Time Error Causing Incorrect Client Computer Time

The time of a virtual machine Domain Controller (DC) was initially set to synchronize with the underlying Hyper-V system, but it ended up being more than a minute off from the correct time.

The time displayed on PDC files was accurate, indicating that not all client computers had incorrect time settings. It depended on which DC the clients synchronized their time with.

Initially, the DC with the time error was adjusted using a small utility called NTPCLOCK to set the correct time. However, after a short while, it reverted back to the incorrect time. When running the command "w32tm /query /configuration" on the server, the configuration showed a section called "VMICTimeProvider" with enable=1, indicating synchronization with the underlying Hyper-V system.

To resolve this, the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider was located, and the "enable" value was changed to 0. There was no need to restart the server. Afterward, the correct time could be set using NTPCLOCK.

For client computers that didn't want to wait for a reboot to synchronize their time, a command could be executed to force synchronization. By running cmd as an administrator and entering "w32tm /resync," the synchronization process would begin. The time wouldn't immediately become correct but would gradually narrow the gap with the accurate time. Patience was required.

Observing the client's clock, if the client's time was slower, one would notice that the seconds occasionally jumped ahead and slowly caught up with the correct time.

弱點掃描 Vulnerable' cipher suites 處理

在用弱點掃描軟體做伺服器弱點檢查時，有些主機有下列這個弱點被掃出: 

Vulnerable' cipher suites accepted by this service via the TLSv1.0 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.1 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

就是有3個TLS的連線協定用了不安全的密碼套件TLS_RSA_WITH_3DES_EDE_CBC_SHA。

網路上比較多的解決方法是用IISCrypto這套軟體，免安裝，直接在伺服器上執行，它會列出很多種連線協定跟密碼套件，把你不要的取消勾選按下套用，重開機，就好了。

也有人說要去改機碼，只是比較麻煩，用IISCrypto比較快。

所以我就在查了一下IISCrypto跟改機碼差在哪，結果是一樣的，IISCrypto背後的方式也是改機碼。

所以就決定自己用改機碼的方式在處理:

因為三個連線協定都是用同一個有問題的密碼套件，因此直接先停用這個密碼套件看看。

原本在Chiphers底下是沒有Triple DES 168，就直接新增，加入這段機碼

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]

"Enabled"=dword:00000000

好了之後不用重開，直接在掃一次，就沒有這三個弱點出現了。

When conducting a vulnerability scan to check for server weaknesses, some hosts may exhibit the following vulnerability:

Vulnerable cipher suites accepted by this service via the TLSv1.0 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

Vulnerable cipher suites accepted by this service via the TLSv1.1 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

Vulnerable cipher suites accepted by this service via the TLSv1.2 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

These vulnerabilities involve the usage of insecure cipher suites, specifically TLS_RSA_WITH_3DES_EDE_CBC_SHA, across all three TLS connection protocols.

One commonly suggested solution found online is to use a software called IISCrypto. It can be executed directly on the server without installation. IISCrypto provides a comprehensive list of connection protocols and cipher suites, allowing users to deselect undesired options, apply the changes, and then reboot the server.

Another approach involves modifying the registry, although this method is considered more cumbersome compared to using IISCrypto, which is faster.

After researching the differences between IISCrypto and registry modification, I discovered that they achieve the same result, as IISCrypto utilizes changes to the registry behind the scenes.

Therefore, I decided to handle the issue by modifying the registry myself:

Since all three connection protocols employ the same problematic cipher suite, the first step was to disable this specific cipher suite.

Initially, the "Triple DES 168" option was not present under the Chiphers section, so I added it directly by inserting the following registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]

"Enabled"=dword:00000000

After applying this modification, there was no need to restart the system. Running another scan revealed the absence of the aforementioned three vulnerabilities.

永豐 shioaji api 登入後只有證券帳號 沒有期權帳號

跟期貨營業員確認已申請好了shioaji的api後，在python下指令要列出帳號清單，發現都只有證券帳號，沒有期權帳號，有點怪。

後來上了永豐api官方的telegram去發問，才知道原來當初在申請api key的時後，因為只有證券戶，期貨戶還沒開好，所以申請api key的過程，只有證券戶可以勾選，所以用那組api key登入時就只有證券帳號可以用。

重新在申請一次api key，勾選期權選項後，登入測試就有列出期權帳戶了。

Greenbone Security Assistant 掃描錯誤 : Interrupted at 0 %

之前建了一台 Greenbone Security Assistant做弱點掃描，都很正常，掃完就沒管它，過了快一個月，要在掃一些之前掃過的主機時，工作開始後沒多久就會出現"Interrupted at 0 %"的錯誤，重試幾次都一樣，也沒找到什麼資訊，直接重開機吧。

然後就好了!!!!

Greenbone Security Assistant Scanning Error: Interrupted at 0%

Previously, I set up a Greenbone Security Assistant for vulnerability scanning, and everything was working fine. Once the scans were completed, I didn't pay much attention to it. After almost a month, when I tried to scan some hosts that were previously scanned, I encountered an error shortly after starting the scan, stating "Interrupted at 0%". I retried several times, but the error persisted, and I couldn't find any helpful information. Eventually, I decided to restart the machine.

And guess what? The issue was resolved after the restart!

突然連不到共用資料夾 error code:0x8007003

 某電腦突然無法連線到任何共用資料夾，不管是windows分享的或nas分享的。

直接ping分享的主機名稱或ip都有通，但要連資料夾都會出現0x8007003的錯誤。

查了一下，原來是dns client這個服務被關閉了，預設應該要是自動才對，把這個服務在啟動後，問題就解決了。

Suddenly unable to connect to the shared folder error code: 0x8007003

A certain computer suddenly cannot connect to any shared folders, whether they are shared through Windows or NAS.

Directly pinging the hostname or IP of the shared host is successful, but when trying to connect to the folders, an error with the code 0x8007003 appears.

Upon investigation, it was discovered that the DNS client service had been disabled. It should be set to automatic by default. After starting this service, the issue was resolved.

synology升級失敗"此檔案可能已損毀"

 Synology的firmware太舊，管理程式也太舊，要在管理介面上用自動更新。

但卻一直顯示這個是最新版了，所以就手動去下載最新的版本來用手動更新。

結果下載好的檔案透過管理介面上傳後卻一直顯示此檔案可能已損毀。

試了幾個比較新的版本都如此。

然後查了一下才發現原本的版本太舊(6.2)，沒辦法直接7，要先下載6.3手動更新，更新完成後，自動更新的功能也恢復正常，就利用自動更新在升到最新版就行了。

Failed Synology upgrade: "This file may be corrupted"

The firmware on the Synology device is too outdated, as well as the management software. To perform an update, the automatic update option is selected within the management interface.

However, the system keeps showing that the current version is the latest, so the decision is made to manually download the latest version and perform a manual update.

After downloading the file, it is uploaded through the management interface, but an error message stating that the file may be corrupted keeps appearing.

Several newer versions are attempted, but the issue persists.

Upon further investigation, it is discovered that the original version (6.2) is too outdated to directly upgrade to version 7. It is necessary to first download version 6.3 and perform a manual update. After completing the update, the automatic update functionality is restored, allowing for an upgrade to the latest version using the automatic update feature.

OPENVAS(GVM)進行弱點掃描會造成網域帳號被鎖住

在使用 OPENVAS對內部電腦進行弱點掃描，發現一個問題，就是會造成一些AD帳號因輸入太多次錯號密碼被鎖住。

個人猜測是在做掃描時，可能會隨便找一些帳號做登入測試，剛好有人的帳號就是一樣的，所以就被鎖了。

帳號被鎖，可以參考下列這個網站的教學，來查是哪一台設備在在做登入驗證的行為。

https://evotec.xyz/active-directory-how-to-track-down-why-and-where-the-user-account-was-locked-out/

OPENVAS(GVM) Vulnerability Scanning Causing Domain Account Lockouts

During the use of OPENVAS for vulnerability scanning on internal computers, I encountered an issue where it resulted in some AD accounts getting locked due to multiple incorrect password attempts. My personal speculation is that during the scanning process, the tool may attempt to log in using random accounts, and if there happens to be a match with a valid account, it leads to the account being locked.

To determine the source of the account lockouts, you can refer to the tutorial provided on the following website. It explains how to track down the device responsible for the login authentication attempts:

https://evotec.xyz/active-directory-how-to-track-down-why-and-where-the-user-account-was-locked-out/

centos 8 yum 更新失敗 - 同步倉庫 'AppStream' 快取失敗，忽略這個 (Failed to synchronize cache for repo)

新架了一台Centos 8的主機，要用yum先做一些元件更新時，都會跳出同步baseos/appstream/extract 快取失敗的問題。

查了一下，原來是centos8的repo路徑有變，但設定檔裡的路徑還是舊的，所以要改掉。

設定檔的路徑在/etc/yum.repos.d/，裡面有很多xxx.repo檔，檔案裡都有一個baseurl=httpxxxxxxxxxxxxxxxxxxxxxx的路徑，要改掉。

大部分國外的網站都說是把原本的mirror.centos.org改到vault.centos.org，大陸那邊的網站則是說改到http://mirrors.cloud.aliyuncs.com。

後來研究了很久，自己是改到https://mirrors.aliyun.com/centos/8-stream/xxxxxxx，這個網站可以直接用瀏覽器連上，後面的xxxx是要看你的錯誤訊息，看你是哪個快取找不到，就去網站上找到相對應的路徑，貼到設定檔上，就行了。

如果出現下列訊息，也會有可能是提供的網站已不存在，所以會有403的錯誤碼。

搞了兩天才弄好，分享給大家看一下，另外就是防火牆要注意，因為後來發現設定沒錯，但還是連不上，是因為自己的防火牆有擋一些東西，所以如果設定改好還失敗，可以查檢一下防火牆。

CentOS 8 Yum Update Failure - Failed to Synchronize Cache for 'AppStream' Repository

I encountered an issue with my newly deployed CentOS 8 server where I couldn't perform component updates using Yum. Every time I tried, I received an error indicating the failure to synchronize the baseos/appstream/extract cache.

After investigating, I discovered that the repository paths for CentOS 8 had changed, but the configuration files still contained the old paths, requiring modification. The configuration files are located in /etc/yum.repos.d/ and contain multiple xxx.repo files. Within each file, there is a baseurl=httpxxxxxxxxxxxxxxxxxxxxxx path that needs to be updated.

Most foreign websites suggested replacing the original mirror.centos.org with vault.centos.org, while some Chinese websites recommended using http://mirrors.cloud.aliyuncs.com. After extensive research, I found that modifying it to https://mirrors.aliyun.com/centos/8-stream/xxxxxxx worked for me. This website can be accessed directly through a browser, and the xxxxxx part depends on the error message you receive. Look for the corresponding path on the website and paste it into the configuration file.

If you encounter the following message, it's possible that the provided website no longer exists, resulting in a 403 error code.

After spending two days troubleshooting, I wanted to share this solution. Additionally, be mindful of your firewall settings. In my case, even though my configuration was correct, I still couldn't establish a connection. It turned out that my firewall was blocking certain elements. So, if you've made the necessary configuration changes but are still experiencing issues, check your firewall settings.

powershell get 資料後以表格寄出

 有時後要用powershell去撈一些資料，然後寄出，如果已經用powershell篩出要的資料再寄出，語法不難，網路上一堆。

但假設我撈出了兩欄資料，我希望寄出來，是有表格的型式，這就難了。

在爬了一堆文後，找到一篇很實用的文章

https://evotec.xyz/sending-html-emails-with-powershell-and-zero-html-knowledge-required/

一開始就是先用get-xxx去把要的資料找出來，並且設成一個變數。

二是建立一個迴圈，把撈出來的資料依序帶入到一個表格容器裡面，設成一個變數。

三是用html語法建立一個表格，設定表格的樣式，抬頭名稱，欄位名稱，然後把步驟二的資料放到這個html的表格內，也是要設成一個變數。

四就是最後一步，用powersell發mail的指令發信，信的內容就是把步驟三產生的變數帶入，就完成了。

依照這個架構，就可以利用powershell去產出表格資料寄給需要的人。

Sometimes, I need to fetch data using PowerShell and then send it out. If I have already filtered the desired data using PowerShell, sending it out is not difficult, as there are plenty of examples available online.

However, if I want to send the fetched data in a tabular format, it becomes more challenging.

After searching through various resources, I found a very useful article:

https://evotec.xyz/sending-html-emails-with-powershell-and-zero-html-knowledge-required/

First, I use "Get-xxx" commands to retrieve the desired data and store it in a variable.

Next, I create a loop to iterate through the fetched data and populate it into a table container, which is stored as another variable.

Then, I use HTML syntax to create a table, set its style, define column headers, and incorporate the data from the previous step into the HTML table, which is stored as a variable as well.

Finally, in the last step, I use PowerShell's email sending command to send the email, and the content of the email is populated by inserting the variable generated in the previous step.

By following this framework, I can utilize PowerShell to generate tabular data and send it to the intended recipients.

永豐 shioaji api 一直登入失敗 ValueError

 一開始學習就充滿挫折~

裝好shioaji套件後，最一開始就是先登入，在這關就卡三天，找到網路上一些教學，也有官方出的PDF檔文件，結果登入後都很怪，雖然有session up的字眼出現，但又有產生其他錯誤。

登入後常會看到這兩種錯誤訊息

ValueError: The seed must be exactly 32 bytes long或ValueError: Invalid character '0'

後來又在官網上在仔細查看，發現了一小段重要的說明，就是以前登入的帳號密碼，是跟下單軟體一樣，用身份證字號去登入，但現在api的登入帳號密碼已經不同了。

是要先去永豐金理財網這個網站，登入後裡面有個API管理的功能，新增一組系統自動產生的超長帳號跟密碼來搭配api登入，程式碼也跟舊的不太一樣，可以參考官網的教學 https://sinotrade.github.io/zh_TW/tutor/login/  

照網站教的，api登入就成功了，不會有那些奇怪的錯誤訊息。