Troubleshooting 100101043 and 100101044 Errors in Access Manager



By: ncashell

August 15, 2007 9:40 am

Reads: 830

Comments:1

Rating:0

Introduction
Flow of Events when Accessing an AG Protected Resource
Validating Metadata Information
Troubleshooting Steps

Introduction

With Novell Access Manager, the Access Gateway includes a Tomcat application that acts as a Liberty Service Provider (SP). This SP communicates with a Liberty Identity Server (IDP), available with the Access Manager Identity Server component, and exchanges sensitive information specific to that user. In order to securely exchange data between the SP and IDP, a circle of trust needs to be established between these two devices.

To build a circle of trust, a network must be built between the service providers (SPs) and the identity provider (IDP). A valid request for federation from an SP to an IDP will be generated only if the IDP recognizes the originator of the request. An exchange of metadata between the IDP and the SP typically qualifies inclusion of both parties in the circle of trust. The device’s metadata describes a trusted partner involved in federation within a circle of trust. The metadata typically contains public key certificates, key descriptors for message signing, a URL for the SSO service, a URL for the SLO (single logout) service, etc. With Access Manager, this metadata is available and publically accessible on both the Identity Server (https://<identity_server_dns>:8443/nidp/idff/metadata) as well as the Access Gateway (https://<embedded_service_provider_dns>/nesp/idff/metadata).

The 10101043 and 10101044 errors are generated when either the IDP could not load the SPs metadata (100101043), or the SP could not load the IDPs metadata (100101044). This document will describe the steps involved in the metadata validation process, as well as describing the flow of events that occur when accessing a protected resource on the Access Gateway. Since it’s one of the most common Access Manager call generators into Novell Technical Support, this AppNote will describe some troubleshooting tools and steps to allow debugging of such issues.

Flow of Events when Accessing an AG Protected Resource

In terms of the flow of events, what happens is the following (assuming that no previous user authentication exists since the identity server or service provider has been restarted):

Part 1

The user tries to access a protected resource on the Access Gateway that requires authentication (contract associated with the Protected Resource). The proxy on the Access Gateway redirects the browser client to the on board (embedded) service provider to check whether a session for that client exists on this host. This session validity is determined by looking at incoming cookies (IPCZQX03a36c6c0a) and dereferencing the value to see whether a matching entry exists in the local store.

The following summarizes the requests going from the browser to the Access Gateway when initially hitting the protected resource http://www.mylag.com. The embedded service provider on the Access Gateway is https://www.aleris.net; the base URL for the IDP server is https://idpcluster.lab.novell.com.

1. An initial request for protected resource http://www.mylag.com/ is made:

-------------->  GET /		
Host: www.mylag.com

2. AG responds with a redirect to the embedded Service Provider, passing the contract associated with the protected resource we are hitting:

<-------------	  HTTP/1.1 302 Found
Location:https://www.aleris.net:443/LAGBroker?c=custom/name/pwd/email
&%22http://www.mylag.com/%22

3. The browser makes a request to the embedded service provider:

	-------------->  GET /LAGBroker?c=custom/name/pwd/email&%22http://www.mylag.com/%22 
  Host: www.aleris.net

4. The AG responds, telling the browser to initiate a Liberty session at the SP:

<-------------	  HTTP/1.1 302 Found
		        Location:

https://www.aleris.net:443/nesp/app/plogin?c=custom/name/pwd/email

&%22https://www.aleris.net:443/LAGBroker?%22http://www.mylag.com/%22%22
Set-Cookie: IPCZQX03a36c6c0a=0000010093022495686cc53fa04726af68723de6; path=/;
domain=aleris.net

5. The Browser sends request to on board Liberty SP login link:

	-------------->  GET /nesp/app/plogin?c=custom/name/pwd/email&%22https:
//www.aleris.net:443/LAGBroker?%22http://www.mylag.com/%22%22
	Host: www.aleris.net
	Cookie: IPCZQX03a36c6c0a=0000010093022495686cc53fa04726af68723de6

6. The Liberty SP sends a redirect back to the IDP login page with Liberty <AuthnRequest>:

<-------------	  HTTP/1.1 302 Moved Temporarily
Set-Cookie: JSESSIONID=7E34B8AB265A7FA49D0D23C166AAB728; Path=/nesp
Location:

https://idpcluster.lab.novell.com/nidp/idff/sso?RequestID=iduuPe6bZ13yPnhGfgckA12TvjCm8

&MajorVersion=1&MinorVersion=2&IssueInstant=2007-08-07T11%3A52%3A46Z
&ProviderID=https%3A%2F%2Fwww.aleris.net%3A443%2Fnesp%2Fidff%2Fmetadata
&RelayState=https%3A%2F%2Fwww.aleris.net%3A443%2FLAGBroker%3F%2522http%3A%2F%2F
www.mylag.com%2F%2522&consent=urn%3Aliberty%3Aconsent%3Aunavailable
&ForceAuthn=false&IsPassive=false&NameIDPolicy=onetime
&ProtocolProfile=http%3A%2F%2Fprojectliberty.org%2Fprofiles%2Fbrws-art
&AuthnContextStatementRef=custom%2Fname%2Fpwd%2Femail

Part 2

Assuming that no session exists for that user, the browser client will be redirected to the Identity Server login page. This redirect, from the Access Gateway service provider, issues an initial Liberty <AuthnRequest> to an identity provider. A set of parameters is included in the request that allows the service provider to specify desired behavior at identity providers in processing the request e.g. the type of contract the user must authenticate to the Access Gateway protected resource. Check out the Liberty Authentication request (http://www.projectliberty.org/liberty/content/download/2197/14625/file/draft-liberty-idff-protocols-schema-1.2-errata-v3.0.pdf).

7. The browser sends the Liberty <AuthnRequest> to IDP SSO service:

-------------->          GET /nidp/idff/sso?RequestID=iduuPe6bZ13yPnhGfgckA12TvjCm8&MajorVersion=1
&MinorVersion=2&IssueInstant=2007-08-07T11%3A52%3A46Z&ProviderID=
https%3A%2F%2Fwww.aleris.net%3A443%2Fnesp%2Fidff%2Fmetadata&RelayState=
https%3A%2F%2Fwww.aleris.net%3A443%2FLAGBroker%3F%2522http%3A%2F%2F
www.mylag.com%2Fsport%2F%2522&consent=urn%3Aliberty%3Aconsent%3Aunavailable
&ForceAuthn=false&IsPassive=false&NameIDPolicy=onetime&ProtocolProfile=
http%3A%2F%2Fprojectliberty.org%2Fprofiles%2Fbrws-art&AuthnContextStatementRef=
custom%2Fname%2Fpwd%2Femail HTTP/1.1
	Host: idpcluster.lab.novell.com

Part 3

When the Identity Server receives the Liberty <AuthnRequest> request, it needs to determine the validity of the request before prompting the user for their credentials. In order to do this, both parties must exchange their metadata with one another. Failure to exchange this metadata will result in the 100101044 or 100101043 error.

8. The AG requests IDP metadata (output below from catalina.out on the AG SP server).

<amLogEntry> 2007-08-01T11:34:15Z INFO NIDS Application: AM#500105024:
AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#231288CF362B01C28BE28FE1131CA603:  
ESP is requesting metadata from IDP
https://idpcluster.lab.novell.com/nidp/idff/metadata 	</amLogEntry>

9. IDP requests AG metadata (output below from catalina.out on IDP server).

<amLogEntry> 2007-08-01T11:34:15Z NIDS Trace: Method:
LibertySSOProfile.A()Thread: http-0%2F0.0.0.0-8443-Processor5
(1 of 3):CreateAuthContext Password name/password/uri
(2 of 3):Translated class Refeerence http://www.projectliberty.org/schemas/authctx/classes/Password
(3 of 3):https://www.aleris.net:443/nesp/idff/metadata<null(null)>:
 </amLogEntry>

Part 4

Assuming the circle of trust is established, the <AuthnRequest> is processed and the corresponding contract is used by the IDP server to display a login page (or prompt for a user certificate in the case of X.509 authentication).

10. The IDP server sends back the login page.

		<-------------	  HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=F7523917F2A6336C2727CBAE251F7F9E; Path=/nidp; Secure

Part 5

The user enters his/her credentials and the IDP server validates them against a back end authentication server.

Part 6

Assuming the credentials are validated, a new authentication is created on the IDP server for that user, and a user artifact is created. This artifact is sent back from the IDP server to the SP via the browser.

11. The catalina.out entry on the IDP server shows the creation of a new authentication entry into the local database (only visible with a successful login).

	<amLogEntry> 2007-08-06T12:29:13Z NIDS Trace: Method:
NIDPAuthentication.<init>() Thread: http-0%2F0.0.0.0-8443-Processor5
	Created new Authentication:
	   protocol: Liberty 1.2
	   expiration: 1186404253594
	 </amLogEntry>

12. The IDP sends a redirect back to the browser with an artifact:

<-------------	  HTTP/1.1 302 Moved Temporarily
Location:

https://www.aleris.net:443/nesp/idff/spassertion_consumer?SAMLart=

AAPes5VNp6uEtUk248UuJudUGm98zQqrjt80O6Cp1UEiN%2F4JEUSB0jbh&RelayState=
https%3A%2F%2Fwww.aleris.net%3A443%2FLAGBroker%3F%2522http%3A%2F%2Fwww.mylag.com%2F%2522

Part 7

The SP, upon receiving the artifact from the browser, establishes a SOAP backchannel communication directly to the IDP server and sends the artifact over that channel.

13. The catalina.out entry on AG SP server shows the sending of an artifact directly to the IDP server (not via the browser).

************************* Liberty Artifact/SOAP message ************************
	Type: sent
	Sent to: https://idpcluster.lab.novell.com/nidp/idff/soapRelayState: None
	<samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:lib="urn:oasis:names:tc:SAML:1.0:protocol" 
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
IssueInstant="2007-08-01T11:34:24Z" 	MajorVersion="1" MinorVersion="1?
RequestID="idkidaVykMMtbSHF.9xTlLzY7fkN8"> 
<samlp:AssertionArtifact>AAPes5VNp6uEtUk248UuJudUGm98zQqrjt80O6Cp1UEiN%2F4
JEUSB0jbh<
/samlp:AssertionArtifact></samlp:Request>
	************************* End Liberty message ****************************

Part 8

The IDP server responds with a list of attributes requested by the SP over the SOAP backchannel.

14. The catalina.out entry on the IDP server shows the sending of an assertion to the SP server (not via the browser).

<samlp:Status><samlp:StatusCode Value="samlp:Success"/></samlp:Status><saml:Assertion
AssertionID="id8lauFMwiZH0n1HIWOdYc.-WsbWM" IssueInstant="2007-08-03T15:49:57Z"
Issuer="https://idpcluster.lab.novell.com/nidp/saml/metadata" MajorVersion="1"
MinorVersion="0"><saml:Conditions NotBefore="2007-08-03T15:44:57Z"
NotOnOrAfter="2007-08-03T15:54:57Z"/><saml:AuthenticationStatement
AuthenticationInstant="2007-08-	03T15:49:57Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml:Subject>
<saml:NameIdentifierFormat "urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">idrJ8g81v7cGDdY4NJ5XzirD2gHDk
</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod></saml:
SubjectConfirmation></saml:Subject></saml:AuthenticationStatement><saml:
AttributeStatement><saml:Subject><saml:NameIdentifierFormat="urn:oasis:names:
tc:SAML:1.1:nameidformat:unspecified">idrJ8g81v7cGDdY4NJ5XzirD2gHDk</saml:
NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:
names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod></saml:SubjectConfirmation>
</saml:Subject><saml:AttributeAttributeName="uid"AttributeNamespace="urn:
oasis:names:tc:SAML:1.0:assertion"><saml:AttributeValue>ncashell</saml:
AttributeValue></saml:Attribute></saml:AttributeStatement>

Part 9

The SP is updated with session information about that user and its cookie. Subsequent requests from the browser client do not require reauthentication as long at the session cookie is valid.

15. The catalina.out entry on the AG SP server shows the addition of a user to the local authentication database.

<amLogEntry> 2007-08-01T11:34:24Z VERBOSE NIDS Application: AM#600105009:
AMDEVICEID#esp-09C720981EEE4EB4:  SOAP message: 	<NIDPSetSession
XLibid="00000000930223501d70e8ec7eb0205468723de6" hardExpire="912"
id="231288CF362B01C28BE28FE1131CA603" 	pid="B1D_%:*,]K#@Hc0KOH-6jEN0N"
SoftExpire="592"><storetype="ldap"><dn>cn=ncashell,o=novell</dn> 
</store><authentications><contracts><contract>name/password/uri<
/contract> </contracts></authentications><roles><role>NTS</role> 
<role>authenticated</role></roles></NIDPSetSession>
</amLogEntry>

Validating Metadata Information

Step 1: Make sure connectivity exists.

When the SP tries to access the metadata on the IDP server, it sends the request to the hostname defined in the IDP base URL configuration. The base URL in the IDP configuration is used to build all the metadata end points.

By going to the metadata URL of my example IDP server, as shown in Figure 1 below, there are multiple references to https://idpcluster.lab.novell.com/… – which is the IDP server base URL. The idpcluster.lab.novell.com hostname MUST be resolvable by the AG SP.

Figure 1 - IDP metadata URL

Figure 1 – IDP metadata URL

The same applies to the IDP – when the IDP requests the AG metadata, it sends a request to the hostname referenced in the ‘Embedded service providers’ hostname defined in the Admin Console > Access Gateway > Configuration > Reverse Proxies / Authentication screen (figure 2).

Figure 2 - Embedded Service Provider configuration URLs

Figure 2 – Embedded Service Provider configuration URLs

In the above example, the Embedded Service Provider metadata URL is defined. The IDP server must be able to resolve www.aleris.net in the above example; otherwise, the metadata exchange will fail.

Step 2: Make sure the IDP and Embedded Service Provider certificates match the hostnames defined in the metadata URL (see Figure 3).

When the IDP or SP is enabled in secure mode (HTTPS), all communication to these devices will require that the servers send back a server certificate. Not only must the server certificate be assigned to the appropriate device, but the subject name of the server certificate MUST match the base URL of the IDP or SP server it is assigned to.

Using the example from our setup above, the IDP server base URL has a certificate with a subject name of idpcluster.lab.novell.com. This name is added to the NIDP-Connector device store by default when you assign the certificate to the IDP configuration (see Figure 4 below).

The embedded service provider wildcard certificate has a subject name of *.aleris.net (which could also be www.aleris.net). This added manually to the Proxy keystore certificate. After the server certificate is created, the administrator must select the certificate and then go to Actions > Add Certificate to Keystores and select the Proxy keystore.

Figure 3 - Server certificates and corresponding device stores

Figure 3 – Server certificates and corresponding device stores

Figure 4 - Assigning IDP certificate to NIDP-Connector certificate store

Figure 4 – Assigning IDP certificate to NIDP-Connector certificate store

When the IDP and SP communicate with each other to exchange and validate the metadata, the SSL Server Certificate part of the handshake can be decoded to confirm that the right subject name is being sent (see Figure 5).

Figure 5 - SSL Handshake showing a server certificate

Figure 5 – SSL Handshake showing a server certificate

 => 147.2.16.160 (SP) sends SP certificate to IDP server (147.2.16.109) with subject name *.aleris.net
Figure 6 - SSL Handshake showing another server certificate

Figure 6 – SSL Handshake showing another server certificate

 => 147.2.16.109 (IDP) sends IDP certificate to SP server (147.2.16.109) with subject name idpcluster.lab.novell.com

Step 3: Make sure that the issuers of the IDP and Embedded Service Provider certificates are added to the appropriate trusted root containers.

When the server certificates are sent from the IDP server to SP client, and from the SP server to the IDP client, the client side needs to be able to validate the certificates. Part of the validation process is to confirm that the server certificate has been signed by a trusted source. To do this, the issuers of the server certificate (intermediate and trusted roots) must be imported into the right trusted root stores:

  • The intermediates and trusted roots of the SP server certificate must be imported into the NIDP-Truststore, and
  • The intermediates and trusted roots of the IDP server certificate must be imported into the ESP Trust Store

In our example, the CA for both the IDP and SP server certificates was the same (see Figure 6). Also, the administrator needed to select the trusted root certificate and select Add Trusted Roots to Trust Stores to add it to the NIDP-Truststore and ESP Trust Store.

Figure 7 - adding trusted roots to appropriate trust stores

Figure 7 – adding trusted roots to appropriate trust stores

When all has been configured as above, the previously visible 100101044 or 100101043 errors will disappear.

Troubleshooting Steps

If the above configuration steps fail to address your issue, the following tools and steps will help you troubleshoot and fix it.

1. From the Access Gateway console, ping the base URL of the IDP server. Note that this MUST be done with a hostname and not an IP address. Using the curl utility on the LAG, you can also make sure that the metadata is downloadable using the following (as per the example IDP base URL from above):

	# curl -k https://idpcluster.lab.novell.com:8443/nidp/idff/metadata

2. From the IDP server, use “wget” to download the metadata from the SP:

	# wget https://www.aleris.net/nesp/idff/metadata

3. Make sure that the subject name of the SP and IDP server certificates match the URL defined for that service. Go to the Certificates TAB on the Admin Console and verify that the subject name for the server certificates matches the DNS name of the IDP/SP services.

4. Make sure that the server certificates are added to the correct certificate store. In other words, the IDP server certificate must be added to the NIDP-Connector store, and the SP certificate must be added to the Proxy Key Store.

Go to the Certificates tab on the Admin Console and verify that the IDP and SP server certificates are added to the correct devices and stores (see Figure 3). Note that if you are clustering IDP and Ags, you will need to add the certificates to the appropriate stores on ALL devices.

5. Make sure that the trusted roots of the server certificates are added to the appropriate trusted root containers i.e. the trusted roots of the IDP server certificate must be added to the ESP trust store; the trusted roots of the SP server certificate must be added to the NIDP-Truststores.

Go to the Certificates TAB on the Admin Console and verify the IDP and SP trusted root certificates are added to the right devices and trust root stores (see Figure 6). Note that if you are clustering IDP and Ags, you will need to add the certificates to the appropriate stores on ALL devices.

6. Using tcpdump on the IDP server, make sure that the certificates being exchanged match those defined in the Admin Console certificates tab. The following tcpdump options will create a certificate.cap file in the directory where you are running the command from, capturing all SSL data.

	# tcpdump -i any -w certificate.cap -s 0 port 443 or 8443

Use Ethereal or Wireshark to read in the trace and decode your SSL data (see Figure 5).

7. Enable the IDP logging tab to dump more verbose Liberty information to /var/opt/novell/tomcat4/logs/catalina.out on BOTH the IDP and SP servers (see Figure 7).

Figure 8 - IDP debug log options for Liberty authentication

Figure 8 – IDP debug log options for Liberty authentication

After enabling and applying the changes, duplicating the issue once more will add a huge amount of details to the catalina.out file. If the error is the 100101044 error, look at the catalina.out file on the SP server for this specific error code; if the error is the 100101043 error, look at the catalina.out file on the IDP server for the error code.

Below are a few typical entries:

a) The SP cannot resolve the IDP server base URL:

<amLogEntry> 2007-08-06T16:24:56Z INFO NIDS Application: AM#500105024:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#2CA1168DF7343A42C7879E707C51A03C:  
ESP is requesting metadata from IDP  https://idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry>

<amLogEntry> 2007-08-06T16:24:56Z SEVERE NIDS IDFF: AM#100106001: 
AMDEVICEID#esp-	09C720981EEE4EB4:  Unable to load me tadata for Embedded Service
Provider: 	https://idpcluster.lab.novell.com/nidp/idff/metadata, error:
AM#300101046: AMDEVICEID#esp-09C720981EEE4EB4: : 	Attempted to connect to a url
with an unresolvable host name </amLogEntry>

<amLogEntry> 2007-08-06T16:24:56Z INFO NIDS Application: AM#500105039:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#2CA1168DF7343A42C7879E707C51A03C:  
Error on session id 	2CA1168DF7343A42C7879E707C51A03C, error
100101044-esp-09C720981EEE4EB4, Unable to authenticate.  	AM#100101044:
AMDEVICEID#esp-09C720981EEE4EB4: : Embedded Provider failed to load Identity Provider
metadata </amLogEntry>

b) Trusted roots are not imported into appropriate trusted root containers.

<amLogEntry> 2007-08-05T16:07:53Z INFO NIDS Application: AM#500105024:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#D983B08C28D35221D139D33E5324F98F:  
ESP is requesting metadata from IDP 
https://idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry>

<amLogEntry> 2007-08-05T16:07:53Z SEVERE NIDS IDFF: AM#100106001: 
AMDEVICEID#esp-	09C720981EEE4EB4:  Unable to load metadata for Embedded Service
Provider: 	https://idpcluster.lab.novell.com/nidp/idff/metadata, error:
java.security.cert.CertificateException: Untrusted Certificate-	chain 

<amLogEntry> 2007-08-05T16:07:53Z INFO NIDS Application: AM#500105039:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#D983 B08C28D35221D139D33E5324F98F:  Error
on session id 	D983B08C28D35221D139D33E5324F98F, error 100101044-esp-09C720981EEE
4EB4, Unable to authenticate.  	AM#100101044: AMDEVICEID#esp-09C720981EEE4EB4: :
Embedded Provider failed to load Iden tity Provider 	metadata </amLogEntry>

c) The Server Certificate has no valid subject name.

<amLogEntry> 2007-07-05T16:07:53Z INFO NIDS Application: AM#500105024:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#D983B08C28D35221D139D33E5324F98F:  
ESP is requesting metadata from IDP 
https://idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry>

<amLogEntry> 2007-07-05T16:07:53Z SEVERE NIDS IDFF: AM#100106001: 
AMDEVICEID#esp-	09C720981EEE4EB4:  Unable to load metadata for Embedded Service
Provider: 	https://idpcluster.lab.novell.com/nidp/idff/metadata, error: 
Received fatal alert: handshake_failure </amLogEntry>

<amLogEntry> 2007-07-05T16:07:53Z INFO NIDS Application: AM#500105039:
AMDEVICEID#esp-	09C720981EEE4EB4: AMAUTHID#D983 B08C28D35221D139D33E5324F98F:  
Error on session id 	D983B08C28D35221D139D33E5324F98F, error
100101044-esp-09C720981EEE 4EB4, Unable to authenticate.  	AM#100101044:
AMDEVICEID#esp-09C720981EEE4EB4: : Embedded Provider failed to load Identity Provider
metadata </amLogEntry>

8. Occasionally, there are issues where the subject name was auto-generated and despite the entire configuration appearing correct, the 100101044/100101043 error is still reported. Delete the auto-generated certificate and recreate the server certificate manually, making sure that it is added to the relevant devices and stores.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , ,
Categories: Access Manager, Technical Solutions

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

1 Comment

  1. By:pmckeith

    Bryon Quist of Novell Technical Services demonstrates Neil’s troubleshooting tips in a quick and easy video format that walks you through all the steps! It is very helpful when you are under the gun or confused by all the gory details.

    Check it out at this link:
    http://www.youtube.com/watch?v=kkQOQ7Qf1Go

Comment