CUCM-certificaatregeneratie/-vernieuwing
Inhoud
Inleiding Voorwaarden Vereisten
Gebruikte componenten
Wanneer om certificaten opnieuw in te voeren?
Service-impact door de certificaatwinkel Een DRS-back-up maken
Bepaal de gemengde modus
Als het cluster in gemengde modus is
Controleer de beveiliging door standaardinstellingen op het cluster
Maak gebruik van het klaargemaakte cluster voor terugdraaiing naar de optie pre 8.0 Certificaten in specifieke volgorde herstellen
Certificaten in CUCM verwijderen en opnieuw genereren Certificaten opnieuw genereren via CLI
Wat te verwachten?
Certificaten via de CLI verwijderen
Certificaten opnieuw genereren via de web GUI Certificaten verwijderen via de webGUI
Na regeneratie/verwijdering van certificaten LSC installeren/bijwerken via telefoon Conclusie
Inleiding
Dit document beschrijft hoe u certificaten kunt regenereren die gebruikt worden in Cisco Unified Communications Manager (CUCM) release 8.x en hoger. De security by default optie (ITL) en Mixed-Mode (CTL) zijn eveneens aanwezig om ongewenste storingen te voorkomen.
Bijvoorbeeld, hoe te om kwesties van de telefoonregistratie of telefoons te vermijden die configuratieveranderingen of firmware niet accepteren.
Voorzichtig: Aanbevolen wordt altijd de regeneratie van certificaten in een onderhoudsvenster te voltooien.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
CallManager
●
CAPF (Proxy-functie van certificeringsinstanties)
●
IPsec
●
Tomcat
●
TVS (Vertrouwsverificatiedienst)
●
ITLR-herstel (alleen voor CUCM 10.X en hoger)
●
telefoonvertrouwen
●
telefoonvertrouwen
●
telefoonvertrouwen
●
telefooncel
●
LSC’s (plaatselijk belangrijke certificaten)
●
MIC’s (door de fabrikant geïnstalleerde certificaten)
●
Gebruikte componenten
De informatie in dit document is gebaseerd op deze softwareversies:
CUCM release 9.1(2)SU2a,
●
CUCM release 8.x en later
●
De informatie in dit document is gebaseerd op de apparaten in een specifieke
laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.
Wanneer om certificaten opnieuw in te voeren?
De meeste certificaten die na een nieuwe installatie in CUCM worden gebruikt, zijn automatisch afgegeven voor vijf jaar. Merk op dat het tijdbereik van vijf jaar op dit moment niet kan worden gewijzigd in een kortere tijdspanne op CUCM. Een certificaatinstantie (CA) kan echter gedurende vrijwel elk tijdsbestek certificaten afgeven.
Er zijn ook een aantal vertrouwde certificaten (zoals CAPF-trust en CallManager-trust) die vooraf zijn geladen en een langere geldigheidstermijn hebben. Het Cisco Manufacturing CA-certificaat wordt bijvoorbeeld op CUCM-trust winkels geleverd voor specifieke functies en verloopt niet tot het jaar 2029.
Certificaten moeten opnieuw worden gegenereerd voordat zij verstrijken. Wanneer de certificaten op het punt staan te verlopen, ontvangt u waarschuwingen in RTMT (Syslog Viewer) en wordt er een e-mail verzonden met het bericht indien geconfigureerd.
Een voorbeeld van een certificaatverloopbericht dat het CUCM01.der-certificaat gedetailleerd vermeldt, vervalt op 19 mei 14:46 op server CUCM02 op de trust store tomcat-trust wordt hier getoond:
At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following SyslogSeverityMatchFound events generated:
SeverityMatch : Critical
MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days AppID : Cisco Syslog Agent
ClusterID : NodeID : CUCM02
TimeStamp : Fri Sep 05 02:00:16 CEST 2014
Indien de servicecertificaten (certificaatwinkels die niet met vertrouwen zijn geëtiketteerd) reeds zijn verlopen, is het nog mogelijk ze te regenereren. Houd in gedachten dat verlopen certificaten een impact kunnen hebben op uw CUCM-functionaliteit, afhankelijk van de configuratie van het cluster. In de volgende paragrafen worden overwegingen besproken.
Service-impact door de certificaatwinkel
Voor de goede functionaliteit van het systeem is het van cruciaal belang dat alle certificaten in de CUCM-cluster worden bijgewerkt. Als uw certificaten zijn verlopen of ongeldig zijn, kan dit de normale werking van het systeem aanzienlijk beïnvloeden. Er wordt hier een lijst weergegeven van mogelijke problemen die u kunt krijgen wanneer een van de specifieke certificaten ongeldig of verlopen is. Het verschil in impact kan afhankelijk zijn van uw systeeminstelling.
CallManager 3.00 m
TFTP niet vertrouwd (telefoons accepteren geen ondertekende configuratiebestanden en/of ITL-bestanden).
●
De telefoondiensten kunnen worden aangetast.
●
Secure Session Initiation Protocol (SIP)-trunks of media-bronnen (conferentiebruggen, Media Termination Point (MTP), Xcoders, enzovoort) registreren of werken niet.
●
Het AXL-verzoek mislukt.
●
Tomcat.pem
Telefoons kunnen geen toegang krijgen tot HTTPs-services die opgeslagen worden op het CUCM-knooppunt, zoals Corporate Directory.
●
CUCM's web GUI-problemen, zoals de mogelijkheid om servicepagina's te benaderen vanaf andere knooppunten in het cluster.
●
Extension Mobility of Extension Mobility Cross-Cluster-kwesties.
●
Als UCCX (Unified Contact Center Express) is geïntegreerd vanwege beveiligingswijzigingen ten opzichte van CCX 12.5 moet u CUCM Tomcat-certificaat (zelf-ondertekend) of het
Tomcat-wortel- en intermediair certificaat (voor CA ondertekend) in UCCX tomcat-trust Store hebben geüpload omdat dit invloed heeft op Finesse-desktoplogins
●
CAPF.pem
Telefonieën zijn niet echt voor telefoon VPN, 802.1x, of telefoonproxy.
●
Kan LSC certificaten voor de telefoons niet uitgeven.
●
Versleutelde configuratiebestanden werken niet.
●
IPSec.pem
Noodherstelsysteem (DRS)/Noodherstelkader (DRF) werkt mogelijk niet goed.
●
IPsec-tunnels naar Gateway (GW) naar andere CUCM-clusters werken niet.
●
TVS
De telefoon kan HTTPS-service niet echt maken. De telefoon kan geen configuratiebestanden echt maken (dit kan bijna alles op CUCM beïnvloeden).
telefoonvertrouwen
De telefoon VPN werkt niet omdat HTTPS URL van VPN niet kan worden geauthentiseerd.
Opmerking: Als dit niet bestaat, maak je geen zorgen. Dit geldt alleen voor specifieke configuraties.
telefoonvertrouwen
Eerdere CTL/Tokens zijn niet in staat om CTL bij te werken of aan te passen.
Opmerking: Als dit niet bestaat, maak je geen zorgen. Dit geldt alleen voor specifieke configuraties.
telefoonvertrouwen en telefoonvertrouwen
Visuele voicemail met Unity Connection werkt niet.
Opmerking: Als dit niet bestaat, maak je geen zorgen. Dit geldt alleen voor specifieke configuraties.
LSC’s en MIC’s
Telefoons registreren niet, authenticeert de telefoon niet aan telefoon VPN, telefoonproxy of 802.1x.
Opmerking: MICs zijn standaard op de meeste telefoonmodellen. LSC’s worden door CAPF ondertekend en hebben een looptijd van vijf jaar. Softwareklanten zoals CIPC (Cisco IP Communicator) en Jabber hebben geen MIC geïnstalleerd.
Een DRS-back-up maken
Het wordt aanbevolen een DRS-back-up te maken voordat u belangrijke wijzigingen zoals deze uitvoert. back-ups van CUCM DRF maken back-ups van alle certificaten in het cluster. Alle procedures voor back-up/herstel van het DRS kunnen worden gevonden in de Cisco Disaster Restore System Management Guide voor Cisco Unified Communications Manager.
Voorzichtig: Houd Cisco bug-ID CSCtn50405 in gedachten, geen back-upcertificaten voor CUCM DRF Backup.
Bepaal de gemengde modus
Om te bepalen als u een CTL/Secure/Mixed-Mode cluster runt, kies Cisco Unified CM-beheer >
Systeem > Enterprise-parameters > Cluster security modus (0 = niet-beveiligd); 1 = = Gemengde modus).
Als het cluster in gemengde modus is
Als u een CUCM-cluster in Gemengde modus uitvoert, betekent dit dat het CTL-bestand moet worden bijgewerkt nadat alle certificaatwijzigingen zijn uitgevoerd. De procedure voor het doen van dit werk bevindt zich in de documentatie met de Security Guide van Cisco. Zorg er echter voor dat u ten minste één token hebt vanaf de oorspronkelijke start van de functie Gemengde modus en dat het Token-wachtwoord bekend is.
Opmerking: Een update van het CTL gebeurt niet automatisch (zoals het in het geval van het ITL dossier doet). Het moet handmatig worden ingevuld door de beheerder met de CTL- client of de CLI-opdracht.
In CUCM 10.X en later kunt u het cluster op twee manieren in gemengde modus zetten:
CLI opdracht - als deze methode wordt gebruikt, wordt uw CTL-bestand getekend met het CallManager.pem-certificaat van de Publisher Server.
admin:show ctl
The checksum value of the CTL file:
0c05655de63fe2a042cf252d96c6d609(MD5)
8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)
Length of CTL file: 4947
The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015 [...]
CTL Record #:1 ----
BYTEPOS TAG LENGTH VALUE --- --- --- --- 1 RECORDLENGTH 2 1156
2 DNSNAME 16 cucm-1051-a-pub
3 SUBJECTNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
6 SERIALNUMBER 16 70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB 7 PUBLICKEY 140
8 SIGNATURE 128
9 CERTIFICATE 694 E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21 A5 A3 8C 9C (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
●
CTL client - als deze methode wordt gebruikt dan wordt uw CTL bestand getekend met een van de hardware Tokens.
admin:show ctl
The checksum value of the CTL file:
256a661f4630cd86ef460db5aad4e91c(MD5)
3d56cc01476000686f007aac6c278ed9059fc124(SHA1)
Length of CTL file: 5728
The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015
●
[...]
CTL Record #:5 ----
BYTEPOS TAG LENGTH VALUE --- --- --- --- 1 RECORDLENGTH 2 1186 2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems 4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems 6 SERIALNUMBER 10 83:E9:08:00:00:00:55:45:AF:31
7 PUBLICKEY 140
9 CERTIFICATE 902 85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93 3E 8B 3A 4F (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
Opmerking: u kunt tussen de methode die wordt gebruikt in de gemengde CUCM-modus en de modus Tokenless CTL bewegen.
Afhankelijk van de methode die wordt gebruikt om uw cluster te beveiligen, moet een geschikte CTL update procedure worden gebruikt. Voer de CTL client opnieuw in of voer de utils ctl update CTLfile opdracht van CLI in.
Controleer de beveiliging door standaardinstellingen op het cluster
Het vermijden van ITL kwesties is belangrijk omdat het veel eigenschappen kan veroorzaken om te mislukken of de telefoon weigert om zich aan elke verandering in configuraties te houden. De ITL kwesties kunnen op deze twee manieren worden vermeden.
Maak gebruik van het klaargemaakte cluster voor terugdraaiing naar de optie pre 8.0
Deze optie maakt uw ITL op alle servers leeg, zodat de telefoons op elke TFTP-server
vertrouwen. De telefoondiensten (bijvoorbeeld, extensie mobiliteit) werken niet wanneer deze parameter op True wordt ingesteld. U kunt echter wel basisoproepen maken en ontvangen.
Opmerking: een verandering in deze parameter veroorzaakt dat ALLE TELEFOONS OPNIEUW WORDEN INGESTELD.
Zodra deze functie is ingesteld, moeten alle TFTP-servers opnieuw worden gestart (om de nieuwe ITL te kunnen leveren) en moeten alle telefoons worden gereset om ze te dwingen om de nieuwe lege ITL te vragen. Nadat de certificaatveranderingen zijn voltooid en alle benodigde services opnieuw zijn gestart, kan deze functie worden teruggezet op False, TFTP-service opnieuw wordt gestart en de telefoon opnieuw worden ingesteld (zodat de telefoon het geldige ITL-bestand kan verkrijgen). Vervolgens blijven alle functies werken zoals voorheen.
Certificaten in specifieke volgorde herstellen
Deze procedure biedt een TFTP-server een geldig/bijgewerkt ITL-bestand van een vertrouwde
TFTP-server die beschikbaar is.
Stop de TFTP-service op de primaire TFTP-server.
1.
Breng wijzigingen aan in de certificaten van de Primaire TFTP-server (indien nodig).
2.
Zet de telefoons terug (om een nieuw ITL bestand te krijgen van de secundaire TFTP server) - afhankelijk van welke certificaten worden geregenereerd, kan dit automatisch gebeuren.
3.
Zodra telefoons zijn teruggegeven, start de TFTP-service van de Primaire TFTP-server.
4.
Wijzig het certificaat op de secundaire TFTP-server.
5.
Zet de telefoons terug (om een nieuw ITL bestand te krijgen van de primaire TFTP server).
6.
Voorzichtig: Geen certificaten op beide TFTP-servers tegelijk bewerken. Dit geeft de telefoons op TFTP server om te vertrouwen en vereist dat de lokale beheerder de ITL van alle telefoons handmatig verwijdert.
Certificaten in CUCM verwijderen en opnieuw genereren
Alleen servicecertificaten (certificaatwinkels die niet zijn voorzien van het label "-trust") kunnen worden gegenereerd. Certificaten in de trustwinkels (certificaatwinkels die zijn voorzien van het label "-trust") moeten worden verwijderd, omdat ze niet kunnen worden gegenereerd.
Voorzichtig: Let op Cisco bug-ID CSCut58407 - Apparaten mogen niet opnieuw opgestart worden wanneer CAPF / CallManager / TVS-trust is verwijderd.
Na alle wijzigingen in het certificaat moet de betreffende service opnieuw worden gestart om de wijziging aan te brengen. Dit wordt geregeld in het gedeelte Na regeneratie/verwijdering van de certificaten.
Voorzichtig: Let op dat Cisco bug-ID CSCto86463 - verschoven certificaten worden
herkend, zodat deze niet meer certificaten uit CUCM kunnen verwijderen. Dit is een uitgifte waarbij de verwijderde certificaten na verwijdering opnieuw verschijnen. Volg de
wasvoorschriften bij het defect.
Certificaten opnieuw genereren via CLI
Voorzichtig: Regeneraties van certificaten starten een automatische update van de ITL bestanden binnen de cluster, die een clusterbrede softphone reset in werking stelt om telefoons in staat te stellen om een update van hun lokale ITL te activeren. Dit is gericht op CAPF en CallManager certificaatregeneraties maar kan met andere certificatenwinkels binnen CUCM, zoals Tomcat, voorkomen.
Opgeven CAPF: Na regeneratie uploadt het CAPF-certificaat zichzelf automatisch naar CAPF- trust en CallManager-trust. CAPF heeft ook altijd een unieke Onderwerp Naam header, dus eerder gebruikte CAPF-certificaten zullen behouden blijven en gebruikt worden voor authenticatie.
set cert regen CAPF
Opmerking: Als een CAPF-certificaat is verlopen, kunnen telefoons die LSC gebruiken niet naar CUCM registreren omdat CUCM hun certificaat afwijst. U kunt echter nog steeds een nieuwe LSC voor de telefoon genereren met het nieuwe CAPF-certificaat. Wanneer u de telefoon opnieuw opstart, downloads het de configuratie en neemt u vervolgens contact op met CAPF om LSC bij te werken. Nadat de LSC is bijgewerkt, registreren de
telefoonregisters zoals het hoort. Dit werkt zolang een nieuw CAPF certificaat in het ITL bestand is en de telefoon gedownload en vertrouwde het certificaat dat het ondertekende (callmanager.pem).
CallManager opnieuw genereren: Na regeneratie uploadt de CallManager zichzelf automatisch om CallManager te vertrouwen.
set cert regen CallManager
IPsec opnieuw genereren: Na regeneratie uploadt het IPsec-certificaat zichzelf automatisch om een IPsec-vertrouwen te creëren.
set cert regen ipsec
Tomcat opnieuw genereren: Na regeneratie uploadt het Tomcat-certificaat zichzelf automatisch om te vertrouwen.
set cert regen tomcat
TVS regenereren:
set cert regen TVS
Wat te verwachten?
Wanneer u certificaten via de CLI regenereert, wordt u gevraagd deze wijziging te controleren.
Typ ja en klik vervolgens op Voer in.
admin:set cert regen CAPF
WARNING: This operation will overwrite any CA signed certificate previously imported for CAPF
Proceed with regeneration (yes|no)? yes
Successfully Regenerated Certificate for CAPF.
You must restart services related to CAPF for the regenerated certificates to become active.
Certificaten via de CLI verwijderen
CAPF-trust certificaten verwijderen
set cert delete CAPF <name of certificate>.pem
Licenties voor CallManager verwijderen
set cert delete CallManager <name of certificate>.pem
vaarbevoegdheidsbewijzen verwijderen
set cert delete ipsec <name of certificate>.pem
Tomat-trust certificaten verwijderen
set cert delete tomcat <name of certificate>.pem
TVS-trust-certificaten verwijderen
set cert delete TVS <name of certificate>.pem
Certificaten opnieuw genereren via de web GUI
Opgeven CAPF:
Na regeneratie uploadt het CAPF-certificaat zichzelf automatisch naar CAPF-trust en
CallManager-trust. Bovendien heeft het CAPF-certificaat altijd een unieke Onderwerp Naam header, zodat eerder gebruikte CAPF-certificaten behouden blijven en gebruikt worden voor authenticatie.
OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate
CallManager opnieuw genereren:
Na regeneratie uploadt het certificaat van CallManager automatisch naar CallManager- vertrouwen.
OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate
IPsec opnieuw genereren:
Na regeneratie uploadt het IPsec-certificaat zichzelf automatisch om een IPsec-vertrouwen te creëren.
OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate
Tomcat opnieuw genereren:
Na regeneratie uploadt het Tomcat-certificaat zichzelf automatisch om te vertrouwen.
OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate
TVS regenereren:
OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate
Certificaten verwijderen via de webGUI
OS Admin > Security > Certificate Management > Find > Click X certificate within the '-trust' store > Remove/Delete
Na regeneratie/verwijdering van certificaten
Nadat u een certificaat uit een certificeringswinkel hebt verwijderd of geregenereerd, moet de desbetreffende service opnieuw worden gestart om de wijziging aan te kunnen.
Bewaren Service om te
herstarten Hoe
Tomcat Tomcat
CLI: utist-service opnieuw opstarten, Cisco Tomcat
Volg indien van toepassing de benodigde stappen vanuit de CCX-omgeving
https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118855-configure-uccx-00.html#anc12
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/release/guide/uccx_b_uccx-solution-release-notes-125/uccx_b_uccx-solution-release-notes-125_chapter_01.html#reference_2D9122E01C43B6E0AA06AB2A3248B797 CallManagerCallManager; TFTP;
CTIManager
Web Gui: Navigeer naar Cisco Unified Services > Gereedschappen > Control Center - Functieservices > (Select Server). Klik onder Cisco CallManager op Start.
WebGui: navigeren naar Cisco Unified Services > Gereedschappen > Control Center - Functieservices > (Select Server). Klik onder Cisco Tftp op Start.
WebGui: navigeren naar Cisco Unified Services > Gereedschappen > Control Center - Functieservices > (Select Server). Klik onder Cisco CTIManager op Start.
CAPF CAPF (alleen op
uitgever) Web Gui: Navigeer naar Cisco Unified Services > Gereedschappen > Control Center - Functieservices > (selecteer Server). Klik onder de functie Cisco Certificate Authority Proxy op Start.
TVS
Vertrouwingsservice (op de betreffende server)
Web Gui: Navigeer naar Cisco Unified Services > Gereedschappen > Control Center - Network Services > (Select Server). Klik onder Cisco Tidal Scheduler op Start opnieuw.
ipsec
Cisco DRF Local (op alle
knooppunten);
Cisco DRF Master (op uitgever)
CLI: Installatieprogramma opnieuw starten Cisco DRF Local Service CLI: utist-service herstart Cisco DRF Master
LSC installeren/bijwerken via telefoon
Als het CAPF-certificaat is geregenereerd, moeten de LSC-certificaten voor alle telefoons in het cluster worden bijgewerkt met LSC die door het nieuwe CAPF-certificaat is ondertekend.
Navigeer naar CUCM Services > Service Activering. Activeert de Cisco CTL Provider en de Proxy-functie van de Cisco certificaatautoriteit op de uitgeverserver.
1.
Onder CUCM CCMAdmin, navigeer naar apparaat > telefoon. Selecteer de IP-telefoon waarop u een LSC wilt activeren.
2.
Op de pagina Apparaatconfiguratie onder certificaatbediening, navigeer naar Installatie/upgrade > by Null String.
3.
Sla de telefoonconfiguratie in CCMAdmin op en kies Config.
4.
Als de telefoon problemen heeft met de installatie van de LSC, voltooi deze acties aan de telefoon:
Wanneer de telefoon opnieuw wordt ingesteld, onder de fysieke telefoon en naar Instellingen > (6) Beveiligingsconfiguratie > (4) LSC > **# (deze handeling ontgrendelt de GUI en stelt ons in staat om verder te gaan met de volgende stap) > Update (de update is niet zichtbaar tot u de vorige stap uitvoert). Klik nu op Inzenden.
Geef geen certificaten aan een telefoon toe tenzij het een draadloze telefoon is (7921/25).
Draadloze telefoons maken gebruik van certificeringsinstanties van derden (CA) om zichzelf te authentiseren.
Conclusie
Als u een probleem hebt of assistentie nodig hebt bij deze procedure, neem dan contact op met het Cisco Technical Assistance Center (TAC) voor assistentie. In dat geval houdt u uw DRF-back- up beschikbaar aangezien deze in laatste instantie gebruikt zal worden om de service te herstellen wanneer TAC dit niet via andere methoden kan doen.
