반응형

웹서버에 워드프레스 설치후 플러그인 다운로드 에러 발생시


APMsetup를 설치하고 웹서버에 워드프레스를 설치하는 것까지 한 후, 워드프레스에 플러그인을 설치할때 다음과 같은 에러가 나는 경우가 있다.


Downloading install package from http://downloads.wordpress.org/plugin/buddypress.2.4.0.zip…

Download failed. There are no HTTP transports available which can complete the requested request.

Return to Plugin Installer


다음 과정을 통하여 해결해 보도록 합니다.

내 페이지에 접속후 로그인하여 대시보드에 진입한다.

좌측 메뉴의 plugins-Add New를 선택하여 플러그인을 추가해 보도록 합니다.

예제로 Buddypress를 설치해 보도록 합니다. Install now 버튼을 클릭하여 설치합니다.


잉? 그러니까 설치가 안된답니다. 왜죠? 

플러그인을 다운로드 받아 수동으로 설치하는것도 번거롭고, 해결책을 찾아 봅시다.


자주 보는 설정진입방법이 또 등장합니다. APMsetup의 서버환경설정을 들어갑니다.



PHP 확장 탭의 php_curl.dll 파일을 체크하고 저장을 누릅니다.

* 플러그인의 종류에 따라 php_openssl.dll도 활성화 해야 할 수도 있다고 합니다. 미리 선택하실분은 선택하셔도 무방합니다만 제 시스템에서는 php_curl.dll만 활성화 해도 잘 동작하였습니다.


작업 표시줄의 APM의 까만 아이콘을 더블클릭 합니다.


정상 작동중인 Apach와 mysql을 정지 합니다.


완전히 중지가 되면 다시 시작 합니다.

참고 : 완전히 재시작 하기 위해 Apache, Mysql 둘다 재시작 하였지만Apache만 재시작 해도 설정파일 적용이 됩니다. 


여기까지 완료하여 서버가 정상 작동중이 되면 다시 플러그인을 다운받아 봅니다.



이제야 플러그인이 설치가 되네요.


참고

웹호스팅 업체로부터 호스팅을 받는 경우 이와 같은 증상이 발생하는 경우 호스팅 업체에 문의하여 php 확장의 php_curl.dll을 셋팅해 달라고 요청을 하시면 됩니다.



출처: http://wassap.tistory.com/170 [Better than Yesterday!]

출처: http://wassap.tistory.com/170 [Better than Yesterday!]

반응형

'IT기술 관련 > 윈도우' 카테고리의 다른 글

Office 365 관련 용어 정리  (0) 2019.04.16
Right VS Permission  (0) 2019.04.09
NTLM 위험 요소  (0) 2017.11.16
NTLM VS Kerberos 인증  (0) 2017.11.16
Winrm 로그 포워딩 방법  (0) 2017.09.26
반응형

출처: https://blog.preempt.com/the-security-risks-of-ntlm-proceed-with-caution


NTLM (NT LAN Manager)은 Windows 2000을 시작하는 Kerberos로 대체 된 Microsoft의 이전 인증 프로토콜입니다. Microsoft Windows 컴퓨터와 서버간에 계정을 인증하기 위해 Microsoft 엔지니어가 설계 및 구현했습니다. 15 년이 넘는 기간 동안 Windows 배포에 대한 기본 설정이 아니었지만 아직 많이 사용되고 있으며 완전히 포기 된 네트워크를 아직 보지 못했습니다. 사실 최신 버전의 Active Directory에서도 지원됩니다.stormy-proceedcaution.png

네트워크에서 NTLM을 사용하면 쉽게 악용 될 수 있으며 조직이 위반 위험에 처하게됩니다. 이 블로그에서는 NTLM이 위험한 이유와 이러한 위험을 완화 할 수있는 최선의 방법을 논의 할 것입니다. [Preempt가 NTLM을 어떻게 도와 줄 수 있는지 보려면이 비디오를확인하십시오 ]

빠른 재미있는 사실

  • NTLM 이전에는 Microsoft에서 LAN Manager (LM) 인증 프로토콜을 사용했습니다.
  • 프로토콜은 IBM과 함께 Microsoft에서 개발했으며 인터넷이 참신하고 사이버 위협이 무섭지 않은 단순한 시대의 상징이었습니다.
  • LM은 극히 약한 암호화 체계를 사용합니다. 현대 연산 장치의 경우 LM 해시는 일반 텍스트 암호를 보내는 것과 거의 같습니다.
  • NTLM은 1993 년에 Windows NT 3.1에서 도입되었으며 나중에 Windows NT 4.0의 두 번째 버전 (NTLMv2)에서 향상되었습니다.
  • NTLMv2는 암호 강도에 대한 몇 가지 보안 향상 기능이 있지만 그 결함 중 일부는 그대로 남아있었습니다.
  • Windows의 최신 버전에서도 NTLM이 지원됩니다.
  • Active Directory는 기본 NTLM 및 Kerberos 구현에 필요합니다.

NTLM 인증 흐름

NTLM을 사용하면 서버에서 생성 된 임의의 챌린지를 암호화하여 서버에 대한 신원을 증명할 수 있습니다.

그림 1은이 흐름을 보여줍니다.

  1. 사용자 컴퓨터가 서버 연결 요청을 보냅니다 (2 단계).
  2. 서버는 임의의 nonce를 생성하여 사용자가 암호화합니다 (3 단계)
  3. 사용자 시스템은 암호 해시로 논스를 암호화하여 암호에 대한 지식을 증명합니다 (4 단계)
  4. 서버는 자체 SAM 데이터베이스의 데이터를 사용하거나 도메인 컨트롤러에서 유효성 검사를 위해 챌린지 - 응답 쌍을 전달하여 올바른 사용자 암호로 암호화 된 챌린지가 실제로 만들어 졌는지 확인하여 사용자 ID의 유효성을 검사합니다 (5-7 단계의 DC 유효성 검사)

NTLM.png

모든 버전의 NTLM이이 흐름을 사용합니다. 버전 간의 주요 차이점은 NTLMv2에서 클라이언트는 클라이언트 넌스와 타임 스탬프를 포함한다는 것입니다. 이렇게하면 오프라인 재생 공격을 완화하는 데 도움이됩니다.

문제점 및 취약점

이제 정말 흥미로운 것들을 위해서. 당신은 매우 책임있는 관리자라고 해봅시다. 모든 시스템이 패치되었는지 확인하십시오. 네트워크 및 엔드 포인트 보호 솔루션이 있습니다. 물론 LM 및 NTLMv1을 사용하지 않도록 설정하면 더 안전한 NTLMv2 만 허용됩니다.

여기에 문제가 있습니다.

약한 암호화

모든 NTLM 버전은 비교적 약한 암호화 체계를 사용합니다. 나는 약점이 거래 차단기가 아님을 동의하지만 해시를 해킹하고 일반 텍스트 비밀번호를 얻는 것이 상대적으로 더 쉽습니다. 첫째, 해시는 상대적으로 약한 MD4를 기반으로합니다. 둘째, 비록 해시가 전선을 통해 전송되기 전에 소금이 칠해 지더라도 해시가 기계의 메모리에 저장됩니다. 그러나 최악의 문제는 시스템에 인증하기 위해 사용자가 대상에서 챌린지에 응답해야하며, 암호가 오프라인 크래킹에 노출된다는 것입니다. 그냥 최근 한이 문제가 얼마나 심각한 설명하기 위해 게시 된 8 자 모든 암호가 거의 표준 하드웨어보다 하루에 금이 될 수있다.

약한 논스

클라이언트와 서버는 DC의 도움없이 자체적으로 챌린지를 위해 넌스 (nonce)를 생성하고 취약한 넌스 (nonce)를 분배하면 악의적 인 위장이 발생할 수 있습니다. 약한 넌센스를 누가 만들 것인지 묻는 경향이있을 수 있으며 그 대답은 Microsoft입니다. 네, 올바르게 들었습니다. 2011 년에는 Microsoft SMB (Server Message Block) 서버 구현이 nonces에 심각한 보안 문제 가 있음을 발견했습니다 이러한 문제는 수정되었지만 약 20 년 동안 발견되지 않았습니다. 이제 타사 서버 및 NTLM 구현과 관련하여 어떤 일이 벌어지고 있는지 상상해보십시오.

다중 요소 인증 없음 (MFA)

엄격하게 암호 기반 인 NTLM은 스마트 카드 및 기타 다중 요소 인증 솔루션에 대한 효과적인 지원이 부족합니다. 물론, 로그인에 스마트 카드를 활용하고 NTLM으로 인증 할 수 있지만, 다른 사람들이 지적했듯이 이것은 (이전 블로그 게시물 에서 언급했듯이 ) 해시를 전달할 수 있기 때문에 전체 스마트 카드 배포를 다소 조롱 거리가됩니다. NT 해시를 직접 사용하십시오.

NTLM 릴레이

이 모든 것들은 메인 코스 전 애피타이저입니다. NTLM의 가장 중요한 문제는 일반적으로 상호 인증을 제공하지 않는다는 것입니다. 이 문제는 그 자체로 문제가되는 반면, NTLM이 재생 및 중간자 공격에 취약해질 수있는보다 심각한 문제로 이어집니다. 이는 사용자가 NTLM을 통해 서버를 인증 할 때마다 발생할 수 있습니다. 연결을 가로 챌 수 있고 (실제 침입 또는 손상된 시스템을 통해) 사용자가 자격 증명을 사용하여 네트워크의 서버로 원하는 모든 작업을 수행 할 수 있습니다 기본적으로 중계 NTLM cred 공격의 공격 경로는 2001 년 이후 였으며 여전히 많은 공격 대상 입니다.

한 가지 방법은 모든 컴퓨터에서 SMB 서명을 강제하는 것입니다. 그러나이 구성은 네트워크 전체에서 시행하기가 어려우므로 HTTP를 통한 NTLM이 여전히 악용 될 수 있기 때문에 문제를 부분적으로 만 해결할 수 있습니다. 이 NTLM 문제를 사용한 최근의 악용 (다른 문제와 함께)은 Hot Potato입니다 .이 약점을 통해 손님 계정으로 코드를 실행하는 모든 Windows 컴퓨터에서 로컬 관리자 권한을 얻을 수 있습니다. Microsoft가 이러한 취약점에 대해 나열한 완화 방법 중 하나는 네트워크 보안을 유지하는 것이며 이러한 취약점은 네트워크에 이미 심각한 위반이있는 경우에만 악용 될 수 있다고 명시합니다. 오늘날의 "위반 가정"사고 방식으로 이것은 만족스럽지 않습니다.  

올해의 Black Hat 컨퍼런스에서 보안 연구원 인 Hormazd Bilimoria와 Jonathan Brossard는 Internet Explorer (또는 Edge)를 속여 로컬 인트라넷에없는 서버에 인증함으로써 NTLM 릴레이를 사용 하여 인터넷에서 네트워크를 손상시킬 수있는 방법을 보여주었습니다 악성 img 태그를 사용하여 또한 여러 가지 응용 프로그램 (MS 및 타사 모두)에서 모두 사용되어 특정 DLL을 사용하여 문제가 모두 안전하지 않다는 것을 보여주기까지했습니다. 즉, Internet Explorer (또는 Edge)가 기적적으로 패치 된 경우에도 취약한 응용 프로그램이 많이있을 수 있습니다.

결론

NTLM이 위험하다는 메시지를 받았기를 바랍니다. 그리고 조직의 네트워크에서주의해서 (완전히 제한되지는 않지만) 사용해야합니다. 사실, 결함 중 일부는 프로토콜의 가장 깊은 부분에 뿌리를두고 있기 때문에 최신 Windows 버전 중 일부가 패치되기 전까지 패치되지 않습니다. 그렇다면 왜 NTLM은 여전히 ​​주위에 있습니까? 레거시 프로토콜이기 때문에 아무 것도 깨지 않으면 서 네트워크에서 제거하기가 매우 어렵습니다. Microsoft는 NTLM을 제한하기위한 지침 을 제공합니다. 이 가이드에서는 모든 NTLM 트래픽을 감사하고 NTLM을 사용하는 서버와 사용자를 분석 한 다음 NTLM을 제한 한 후 사용을 중단하고 예외로 설정해야하는지 판단합니다.

나중에 블로그에서 NTLM을 제거하는 것이 어려운 이유와 UEBA (User Entity and Behavior Analysis) 솔루션을 사용하여 누가 NTLM을 사용하는지 분석하고 결정하고 네트워크의 위험을 평가하며 NTLM을 줄일 수있는 모든 이유에 대해 논의 할 것입니다 공격 표면.

반응형
반응형

출처: https://msdn.microsoft.com/en-us/library/aa480475.aspx


l  NTLM 단점

1) MD4기반의 약한 암호화

2) 클라이언트와 서버는 DC도움 없이 자체적으로 넌스(nonce)를 생성하는데 취약한 넌스(nonce)를 분배하면 악의적인 위장이 발생

3) 다중인증 요소가 없음 (MFA)

4) NTLM 릴레이 - MS2017-8563

           - 상호 인증이 없기 때문에 발생

           - 모든 컴퓨터에 SMB 서명을 강제로 하면 괜찮지만 모든 네트워크에 구성하기 힘듬

          

l  커버러스가 NTLM 보다 좋은점

1) 상호 인증

2) 위임 지원

 

l  exploitdb.com 취약점 개수

NTLM : 12

Kerberos : 14

 

l  최신 취약점 날짜

NTLM : 2017-7-11

Kerberos : 2017-7-11



NTLM 인증

NTLM은 Windows NT 및 Windows 2000 Server 작업 그룹 환경에서 사용되는 인증 프로토콜입니다. 또한 Windows NT 시스템을 인증해야하는 혼합 된 Windows 2000 Active Directory 도메인 환경에서도 사용됩니다. Windows 2000 Server가 하위 수준의 Windows NT 도메인 컨트롤러가없는 기본 모드로 변환되면 NTLM이 비활성화됩니다. 그런 다음 Kerberos v5가 엔터프라이즈의 기본 인증 프로토콜이됩니다.

NTLM 인증 메커니즘

그림 1은 NTLM 프로토콜을 보여줍니다.

Ff647076.ntlmauthentication (ko-kr, PandP.10) .gif

그림 1. NTLM 챌린지 / 응답 메커니즘

챌린지 / 응답 메커니즘은 다음과 같습니다.

  1. 사용자 요청 액세스 . 사용자가 사용자 자격 증명을 제공하여 클라이언트에 로그온하려고합니다. 로그온하기 전에 클라이언트 컴퓨터는 암호 해시를 캐시하고 암호를 삭제합니다. 클라이언트는 요청과 함께 일반 텍스트로 사용자 이름을 포함하는 요청을 서버로 보냅니다.
  2. 서버가 챌린지 메시지를 보냅니다 . 서버는 challenge 또는 nonce라고하는 16 바이트의 난수를 생성하여 클라이언트에 전송합니다.
  3. 클라이언트가 응답 메시지를 보냅니다 . 클라이언트는 사용자의 암호에서 생성 된 암호 해시를 사용하여 서버가 보낸 챌린지를 암호화합니다. 이 암호화 된 챌린지를 응답 형식으로 서버에 다시 보냅니다.
  4. 서버가 도메인 컨트롤러에 대한 요청 및 응답을 보냅니다 . 서버는 사용자 이름, 원래의 시도 및 응답을 클라이언트 컴퓨터에서 도메인 컨트롤러로 보냅니다.
  5. 도메인 컨트롤러는 사용자 인증을 위해 요청과 응답을 비교합니다 . 도메인 컨트롤러는 사용자의 암호 해시를 가져온 다음이 해시를 사용하여 원래의 챌린지를 암호화합니다. 그런 다음 도메인 컨트롤러는 암호화 된 챌린지를 클라이언트 컴퓨터의 응답과 비교합니다. 일치하는 경우 도메인 컨트롤러는 사용자가 인증되었음을 확인하는 서버를 보냅니다.
  6. 서버가 클라이언트에 응답을 보냅니다 . 유효한 신임장을 가정하면, 서버는 클라이언트가 요청 된 서비스 또는 자원에 대한 액세스 권한을 부여합니다.

Kerberos 인증

Kerberos 인증은 NTLM 인증보다 다음과 같은 이점을 제공합니다.

  • 상호 인증 . 클라이언트가 특정 서버의 특정 서비스와의 인증에 Kerberos v5 프로토콜을 사용하는 경우 Kerberos는 클라이언트가 네트워크의 악의적 인 코드에 의해 서비스가 가장하지 못하도록 보장합니다.
  • 위임 지원 . Kerberos 인증을 사용하여 클라이언트를 인증하는 서버는 해당 클라이언트를 가장하여 클라이언트의 보안 컨텍스트를 사용하여 네트워크 리소스에 액세스 할 수 있습니다.
  • 성능 . Kerberos 인증은 NTLM 인증보다 향상된 성능을 제공합니다.
  • 단순화 된 신뢰 관리 . 여러 도메인이있는 네트워크에는 더 이상 복잡한 일련의 명시 적, 지점 간 신뢰 관계가 필요하지 않습니다.
  • 상호 운용성 . Microsoft의 Kerberos 프로토콜 구현은 IETF (Internet Engineering Task Force)에 권장되는 표준 트랙 사양을 기반으로합니다. 따라서 Windows 2000에서 프로토콜을 구현하면 Kerberos 버전 5가 인증에 사용되는 다른 네트워크와의 상호 운용성을위한 기반이됩니다.

Kerberos 인증 메커니즘

그림 2는 Kerberos 인증 프로토콜의 간단한보기입니다.

Ff647076.kerberosauthentication (ko-kr, PandP.10) .gif

그림 2. Kerberos 인증

클라이언트가 네트워크 서비스에 대해 인증하면 Kerberos v5 프로토콜은 다음 단계를 수행합니다.

  1. 클라이언트가 KDC에서 TGT를 요청합니다 . 사용자가 사용자 자격 증명을 제공하여 클라이언트에 로그온하려고합니다. 클라이언트 컴퓨터의 Kerberos 서비스는 Kerberos 인증 서비스 요청을 KDC (키 배포 센터)로 보냅니다. 요청에는 사용자 이름, 티켓 부여 티켓 (TGT)이 요청 된 서비스 정보 및 사용자의 장기 키 또는 암호를 사용하여 암호화 된 시간 스탬프가 포함됩니다.
    참고     Windows 2000 Server 또는 Windows Server 2003 운영 체제에서 도메인 컨트롤러는 KDC 역할을하며 Active Directory는 보안 계정 데이터베이스를 호스트합니다.
  2. 인증 서비스는 암호화 된 TGT 및 세션 키를 보냅니다 . KDC는 Active Directory에서 사용자의 장기 키 또는 암호를 가져온 다음 요청과 함께 전달 된 시간 스탬프를 암호 해독합니다. 타임 스탬프가 유효하면 사용자는 정품입니다. KDC 인증 서비스는 로그온 세션 키를 만들고 사용자의 장기 키를 사용하여 복사본을 암호화합니다. 그런 다음 인증 서비스는 사용자 정보와 로그온 세션 키가 포함 된 TGT를 만듭니다. 마지막으로 인증 서비스는 자체 키를 사용하여 TGT를 암호화하고 암호화 된 세션 키와 암호화 된 TGT를 클라이언트에 전달합니다.
  3. 클라이언트는 TGT에서 서버 액세스를 요청합니다 . 클라이언트는 장기 세션 키 또는 암호를 사용하여 로그온 세션 키의 암호를 해독하고 로컬로 캐시합니다. 또한 클라이언트는 암호화 된 TGT를 캐시에 저장합니다. 네트워크 서비스에 액세스 할 때 클라이언트는 사용자의 이름, 사용자의 로그온 세션 키를 사용하여 암호화 된 인증 자 메시지, TGT 및 서비스 이름과 같은 정보를 사용하여 KDC 티켓 부여 서비스 (TGS)에 요청을 보냅니다 및 서버)에 액세스 할 수 있습니다.
  4. TGS는 암호화 된 세션 키와 티켓을 보냅니다 . KDC의 TGS는 자체 키를 사용하여 TGT를 암호 해독하고 로그온 세션 키를 추출합니다. 로그온 세션 키를 사용하여 인증 자 메시지 (일반적으로 타임 스탬프)를 암호 해독합니다. 인증 자 메시지가 성공적으로 해독되면 TGS는 TGT에서 사용자 정보를 추출하고 사용자 정보를 사용하여 서비스에 액세스하기위한 서비스 세션 키를 만듭니다. 사용자의 로그온 세션 키를 사용하여 서비스 세션 키의 복사본 하나를 암호화하고 서비스 세션 키와 사용자 정보가 포함 된 서비스 티켓을 만든 다음 서버의 장기 키 (암호)로 서비스 티켓을 암호화합니다. 그런 다음 TGS는 암호화 된 서비스 세션 키와 서비스 티켓을 클라이언트에 보냅니다.
  5. 클라이언트가 서비스 티켓을 보냅니다 . 클라이언트가 서비스에 액세스하면 서버에 요청을 전송합니다. 요청에는 서비스 세션 키와 서비스 티켓을 사용하여 암호화 된 인증 자 메시지 (타임 스탬프)가 포함됩니다.
  6. 서버는 클라이언트 유효성 검증을 위해 암호화 된 시간 소인을 보냅니다 . 서버는 서비스 티켓을 암호 해독하고 서비스 세션 키를 추출합니다. 서비스 세션 키를 사용하여 서버는 인증 자 메시지 (타임 스탬프)를 해독하고 평가합니다. 인증자가 테스트를 통과하면 서버는 서비스 세션 키를 사용하여 인증 자 (타임 스탬프)를 암호화 한 다음 인증자를 다시 클라이언트로 전달합니다. 클라이언트는 타임 스탬프의 암호를 해독하고 원본과 동일한 경우 서비스가 정품이고 클라이언트가 연결을 계속 진행합니다.

Flavor

Baseline

Pros

Cons

NTLMv1

Meant for Win9X, NT 3.51

Libraries available in deprecated version of open source JCIFS

IE and Windows only, very crackable, susceptible to man-in-the-middle attacks, chatty on network

NTLMv2

Meant for NT 4.0 SP4

More secure than NTLMv1.

  • IE and Windows only, not a part of Java 6's implementation of SPNEGO
  • Requires 3rd party libraries (e.g., jespa or VSJ)
  • Chatty on network

Kerberos

Default authentication for Active Directory

  • Included in Java 6 implementation of SPNEGO
  • More secure than NTLMv2
  • Open standard
  • Cross platform (Windows, Linux, Unix)
  • Cross browser (IE, Firefox)
  • Less chatty than NTLM

Client machine must be joined to domain


반응형
반응형

출처: https://blog.thesysadmins.co.uk/winrm-winrs-and-forwarded-event-logs.html



This post should give you a quick understanding of WinRM, WinRS, forwarding event logs and when you’re likely to see the 0x80338126 error.

WinRM (Windows Remote Management) is Microsoft’s new remote management which allows remote management of Windows machines. It was introduced in Server 2003 R2, but I didn’t really hear much about it until Server 2008.

WinRM is the ‘server’ component and WinRS is the ‘client’ that can remotely manage the machine with WinRM configured.

Differences you should be aware of:

WinRM 1.1
Vista and Server 2008
Port 80 for HTTP and Port 443 for HTTPS

WinRM 2.0
Windows 7 and Server 2008 R2
Port 5985 for HTTP and Port 5986 for HTTPS

WinRM 1.1 can also be downloaded and installed on pre-R2 2003 and XP from here.


WinRM

To enable WinRM head to the command prompt and type winrm qc or winrm quickconfig this does the following:

Performs configuration actions to enable this machine for remote management.
Includes:
1. Start the WinRM service
2. Set the WinRM service type to auto start
3. Create a listener to accept request on any IP address
4. Enable firewall exception for WS-Management traffic (for http only)

It’ll ask you if you want to make these changes, type ‘y’ and press enter.

To verify a listener has been created type winrm enumerate winrm/config/listener

WinRM Client Setup

Just to round off this quick introduction to WinRM, to delete a listener use winrm delete winrm/config/listener?address=*+Transport=HTTP

WinRS

WinRS (Windows Remote Shell) is the client that connects to a WinRM configured machine (as seen in the first part of this post). WinRS is pretty handy, you’ve probably used PSTools or SC for similar things in the past. Here are a few examples of what you do.

Connecting to a remote shell
winrs -r:http://hostnameofclient "cmd"
Stop / Starting remote service
winrs -r:http://hostnameofclient "net start/stop spooler"
Do a Dir on the C drive
winrs -r:http://hostnameofclient "dir c:\"

WinRS

Forwarded Event Logs

This is configured using ‘subscribers’, which connect to WinRM enabled machines.

To configure these subscribers head over to event viewer, right click on forwarded events and select properties. Select the 2nd tab along subscriptions and press create.

This is where you’ll select the WinRM enabled machine and choose which events you would like forwarded.

Subscriptions

Right click the subscription and select show runtime status.

Error 0x80338126

Now it took me a minute or two to figure this one out. Was it a firewall issue (this gives the same error code), did I miss some configuration steps? Well no, it was something a lot more basic than that. Remember earlier on we were talking about the port changes in WinRM 1.1 to 2.0?

That’s right, I was using server 2008 R2 to set the subscriptions which automatically sets the port to 5985. The client I configured initially was server 2008 so uses version 1.1. If you right click the subscription and click properties -> advanced you’ll be able to see this. I changed this to port 80 and checked the runtime status again.

[DC2.domain.local] – Error – Last retry time: 03/02/2011 20:20:30. Code (0x5): Access is denied. Next retry time: 03/02/2011 20:25:30.”

Head back to the advanced settings and change the user account from machine account to a user with administrative rights. After making these changes the forwarded events started to flow.

Subscriptions Advanced

반응형

'IT기술 관련 > 윈도우' 카테고리의 다른 글

NTLM 위험 요소  (0) 2017.11.16
NTLM VS Kerberos 인증  (0) 2017.11.16
NFS,CIFS 차이점  (2) 2017.09.20
WinRM 관련 보안 이슈 확인 및 보안 조치 방안  (0) 2017.09.12
Winrm 보안설정 관련 자료  (0) 2017.09.11

+ Recent posts