Smartcard (reader) niet altijd zichtbaar in Citrix sessie

[Koffie]

We lopen hier al een tijd rond met een groot probleem waar we niet uit komen: Smartcard (readers) komen niet altijd mee in een Citrix sessie.

Voor de gebruiker is het symptoom dat ze niet met de smartcard kunnen werken, in werkelijkheid komt de gehele reader niet aan in de sessie.
Probleem is alleen dat het ook vaak genoeg wel werkt. Er is geen pijl op te trekken wanneer het wel of niet niet werk.

Inmiddels is wel de gedachtegang dat de (user)load van een server negatief effect heeft of het gaat werken of niet. Tests lijken dit beeld te bevestigen.

De readers die we gebruiken zijn de Cardman 3121 USB readers icm met smartcards van het UZI Regsiter.
Onze servers zijn allen HP DL360 G7, Windows 2008 SP2 Standard met XenApp 5.
gebruikerssessies worden gemanaged met PowerFuse 8.

De clients zijn voornamelijk HP TC's van het type 5720 met Windows XP Embedded, maar het probleem doet zich ook voor met een laptop met Windows 7.

Om te verifiëren of een reader meegekomen is of niet, starten we in de sessie het tooltje 'token beheer progrramma' wat met de UZI drivers geïnstalleerd word.
Wanneer 'het niet werkt' is hier de reader in zijn geheel niet te zien, als alles wel werkt staat deze er uiteraard netjes bij.

Wanneer een server het gedrag vertoond dat een nieuwe sessie geen reader meekrijgt, maakt het niet uit hoe je verbind:

- Via een Citrix sessie als user met Powerfuse
- Via een Citrix sessie als admin, zonder Powerfuse
- Via een RDP sessie als admin, zonder Powerfuse

Log ik op zo'n moment aan op een server waar geen gebruikers op zitten, is de kans zo goed als zeker dat het werkt. Log ik weer aan op een 'drukke' server dan werkt het weer niet.

Op mijn eigen laptop heb ik toevallig iets onboard zitten voor cardreaders: een 'RICOH Company, Ltd. RICOJ SmartCard Reader 0'. Deze word ook door de tool gezien als smartcard reader.
Ook deze onboard reader vertoond exact dezelfde symptomen als de Omnikey reader. Dit sterkt mijn aanname dat het niet aan de reader/drivers ligt.

Wanneer Citrix een smartcard doorzet naar een sessie, zou de Client module VDSCARDN.DLL geladen worden voor het aanmaken van een Virtual Channel.
Ik zie deze DLL ook geladen worden wanneer de reader niet aankomt.

Servers herinstalleren is al gedaan, zonder enig resultaat.
Wanneer ik op een willekeurige server weinig gebruikers toe laat, is de kans groot dat het goed werkt. Laat ik er veel op los (geen hard getal, vaak vanaf een user of 30/40) dan is de kans klein dat het bij zulke aantallen werkt.
Wanneer 1 gebruiker zijn reader niet meekrijgt, betekend dit niet dat het voor niemand werkt. Wanneer een gebruiker een werkende situatie heeft blijft dit gedurende zijn sessie altijd werken.

Het verhaal is nogal hak op de tak geschreven, dus ik hoop dat het duidelijk is

[Verwijderd]

Duidelijk verhaal. Ben dit zelf nog niet tegengekomen al moet ik zeggen dat we alleen nog maar Xenapp 6/6.5 hebben draaien.

Heb je hier al eens over nagedacht, is het mogelijk om eens een Xenapp 6.5 farm te maken met load om hier eens op te gaan testen?

Nog wel een vraag over de huidige situatie, welke client veries gebruik je? PNA(oude naam) of Web client? Heb je deze al eens geupgrade?

Hierbuiten zou ik eens een topic aanmaken op het Citrix Xenapp forum, heeft mij ook wel eens geholpen met dit soort problemen.

[MAX3400]

Via een RDP sessie als admin, zonder Powerfuse

Dit is storend en lijkt me minstens het onderzoeken waard!

Je sluit hiermee gelukkig zelf al uit dat het aan de applicaties PowerFuse en/of Citrix kan liggen met bijbehorende policies.

Gezien je verhaal verder heb je geen virtuele omgeving maar ik zou bijna adviseren: pak een lege machine, zet deze in een andere OU, block alle policy-inheritance, zet daar Server 2008SP2 op, verder geen enkele andere "gebruiker-software" en ga maar testen, in batch, 200x aanloggen als admin via RDP en kijken hoe vaak de reader wel/niet mee komt.

[Verwijderd]

MAX3400 schreef op woensdag 04 januari 2012 @ 09:08:
[...]

Dit is storend en lijkt me minstens het onderzoeken waard!

Je sluit hiermee gelukkig zelf al uit dat het aan de applicaties PowerFuse en/of Citrix kan liggen met bijbehorende policies.

Gezien je verhaal verder heb je geen virtuele omgeving maar ik zou bijna adviseren: pak een lege machine, zet deze in een andere OU, block alle policy-inheritance, zet daar Server 2008SP2 op, verder geen enkele andere "gebruiker-software" en ga maar testen, in batch, 200x aanloggen als admin via RDP en kijken hoe vaak de reader wel/niet mee komt.

Die had ik over het hoofd gelezen...pff tis nog vroeg

Wel heel vaag! Maar volgens mij ook al maak je een RDP connectie gebruikt hij nog wel techniek vanuit Citrix...correct me if I am wrong.

[MAX3400]

Verwijderd schreef op woensdag 04 januari 2012 @ 09:12:
[...]


Die had ik over het hoofd gelezen...pff tis nog vroeg

Wel heel vaag! Maar volgens mij ook al maak je een RDP connectie gebruikt hij nog wel techniek vanuit Citrix...correct me if I am wrong.

Correctie: RDP is ongelijk aan ICA... Dat gezegd hebbende; een "vieze" admin heeft zijn Citrix-policies verwerkt in Active Directory waardoor bepaalde zaken alsnog niet netjes hoeven te werken.

Ook vraag ik me af of het probleem niet kan liggen aan de versie-verschillen van de RDP-client en (voor later) de online plugin functionaliteit die mogelijk niet hetzelfde is tussen de thin clients en de laptops.

/edit: even over die VDSCARDN.DLL; die wordt toch "per definitie" geladen op het moment dat er een policy bestaat voor het aanspreken van smartcards/readers of als deze wordt aangeroepen door een ander proces wat binnen de user-sessie wordt opgestart? Deze is alleen benodigd voor het virtual channel maar hoeft hiermee nog niet te betekenen dat de functionaliteit van een reader/smartcard daadwerkelijk "gestart" is?

[ Voor 22% gewijzigd door MAX3400 op 04-01-2012 09:35 ]

[JaNuZz]

Wellicht http://support.citrix.com/article/CTX130285 iets kan oplossen ( alhoewel het probleem ook met rdp optreedt vrees ik van niet.)
Er zijn overigens nog meer hotfixes mbt smartcards en xa5 te vinden, een beetje afhankelijk of je het rollup pack hebt geïnstalleerd. Volgens mij bestaat er jammer genoeg er geen hdx monitor voor xenapp 5 want dan zou je die smartcard kunnen monitoren in je ica sessie.
Ik heb bij een vorige werkgever die uzi passen met dezelfde software op xenapp6 prima draaiend gehad.

Wat ik me anders nog bedenken kan is dat er iets met profielen (iets te traag inladen op een vollere server?) misgaat, ik weet niet of je dat met powerfuse doet en of je daar een extended log kunt inschakelen om het 1 en ander na te kijken, en anders processmonitor eens laten meelopen.

[Koffie]

Dank voor alle antwoorden, ik zal proberen op alles te reageren.

Een XA 6.5 farm gaat waarschijnlijk niet lukken, de impact zal te groot zijn. Het is wel iets wat in mijn achterhoofd speelt, maar ik heb te weinig munitie om het te verdedigen.

Ook met client 11.0.150 treed heb probleem op, welke versie er exact op de TC's draait weet ik even niet uit mijn hoofd.

Het probleem is ook dat het dus onder userload lijkt te gebeuren, en ik dus niet zomaar een hobbybob server vrij kan geven om daar users op los te laten.

Zelf dacht ik dat de VDSCARDN pas geladen word als er een smartcard device is, dat strookt ook met de users die geen reader hebben en ook geen DLL geladen krijgen.

JaNuZz schreef op donderdag 05 januari 2012 @ 21:52:
Wellicht http://support.citrix.com/article/CTX130285 iets kan oplossen ( alhoewel het probleem ook met rdp optreedt vrees ik van niet.)

Eens even kijk of die er ook voor x64 is http://support.citrix.com/article/CTX130286

[Verwijderd]

Koffie schreef op vrijdag 06 januari 2012 @ 11:25:
Dank voor alle antwoorden, ik zal proberen op alles te reageren.

Een XA 6.5 farm gaat waarschijnlijk niet lukken, de impact zal te groot zijn. Het is wel iets wat in mijn achterhoofd speelt, maar ik heb te weinig munitie om het te verdedigen.

Ook met client 11.0.150 treed heb probleem op, welke versie er exact op de TC's draait weet ik even niet uit mijn hoofd.

Het probleem is ook dat het dus onder userload lijkt te gebeuren, en ik dus niet zomaar een hobbybob server vrij kan geven om daar users op los te laten.

Zelf dacht ik dat de VDSCARDN pas geladen word als er een smartcard device is, dat strookt ook met de users die geen reader hebben en ook geen DLL geladen krijgen.


[...]

Eens even kijk of die er ook voor x64 is http://support.citrix.com/article/CTX130286

In dat geval lijkt de beschijving van deze patch wel te kloppen, ik neem aan dat de 1e user sneller logged is dan user nr 30?

Zelf wel eens meegemaakt dat een nieuwere versie meer problemen gaf dan de oude versies i.c.m. oude XenApp versies.

Wat ik nog niet kon vinden in je verhaal, hoe is dit probleem ontstaan? Nieuwe omgeving? Nieuwe kaartlezers? of kwam dit probleem pas nadat de load toenam?

[Koffie]

Eigenlijk is dit heel langzaam gekomen, in combinatie met de dat wij wel dachten dat het werkte en de gebruikers vonden van niet
De load is ook wel wat toegenomen de laatste tijd, maar heel mondjesmaat. Op topdagen hebben we 1400+ concurrent connections draaien.

Ik ga nu testen met die ene patch, kijken wat dat doet.

[WhizzCat]

Ik mis nu alleen ff hoeveel servers jullie hebben?

1400+ concurrent users op 3 DL's is niet handig namelijk, maar dat wist je zelf vast ook wel

Ik kan hier alleen niks zinnigs over zeggen, alleen het feit dat bij ons die dingen gewoon lokaal gebruikt worden zonder Citrix (ook XenApp5 + PF trouwens). Ik ga eens kijken of ik dit samen met de Citrix beheerder op kan pakken want ik zie helaas inderdaad al een horror tafereel voor me van gebruikers die "opeens" vanuit huis weer allerlei beveiligde zorg-sh!t moeten gaan doen

[Koffie]

Nee, we hebben er iets meer
Van de 25 servers hebben we er op dit moment 20/21 in productie.
Een select groep gebruikers die veel met smartcard moeten werken en/of problemen hebben zitten op 1 server. Hierdoor zitten er op die server minder users waardoor de kans groter is dat het werkt.

Zojuist de patch getest, en met 30 users werkte het prima. Probleem: een andere productieserver met 40+ users gaf op dat moment ook geen problemen

update: 43 users op de gepatchde server en geen smartcard in mijn sessie
Op de huidige 'rustige' server voor smartcard users geen probleem (16 users ATM).

[ Voor 15% gewijzigd door Koffie op 06-01-2012 14:20 ]

[Koffie]

Schopje.

Inmiddels zitter er zoveel gebruikers op de 'geisoleerde omgeving' dat ook deze er last van begint te krijgen. Ik heb daar dus een 2e server bijgeschoven.

Ik hoop vanmiddag eens verder in te zoomen op Citrix patches, kijken of ik er eentje over het hoofd heb gezien.
Een test met XA 6.0 of 6.5 gaat voorlopig niet lukken daar we geen R2 draaien (en we dan dus 25 x R2 + 1600 CAL's moeten aanschaffen).

Iemand nog een briljant idee?

[Verwijderd]

Koffie schreef op vrijdag 13 januari 2012 @ 09:25:
Schopje.

Inmiddels zitter er zoveel gebruikers op de 'geisoleerde omgeving' dat ook deze er last van begint te krijgen. Ik heb daar dus een 2e server bijgeschoven.

Ik hoop vanmiddag eens verder in te zoomen op Citrix patches, kijken of ik er eentje over het hoofd heb gezien.
Een test met XA 6.0 of 6.5 gaat voorlopig niet lukken daar we geen R2 draaien (en we dan dus 25 x R2 + 1600 CAL's moeten aanschaffen).

Iemand nog een briljant idee?

Tja, een keer moet je toch om... =) (of je moet wachten op win2012 ofzo)

Een test kan je toch sowieso doen?" Trial win2k8 R2 installeren (180 dagen activatie ofzo?) en dan een trial Xenapp 6.0/6.5?

Zou hiernaast even niks weten, heb je dit al gemeld op het CTX forum?

[Koffie]

Inmiddels al een topic op het Citrix forum, maar nog geen reactie.
Inmiddels zijn we wel een stap verder, maar hierdoor is het nog ingewikkelder geworden

We hebben zelf een klein tooltje geschreven wat aan de WinSCard.dll opvraagt welke readers er allemaal aanwezig zijn.
Dit werkt prima, ook in een ICA/RDP sessie krijg je keurig de doorgemapte readers te zien. Met deze tool wilde wij verder gaan troubleshooten ..
Totdat we er achter kwamen dat in een niet werkende sessie de WinSCard.dll (leeS: ons tooltje) nog steeds keurig verteld welke readers er zijn.
Dus: Daar waar de situatie zich voordoet dat er volgens ons geen reader doorgemapped word, blijkt deze wel degelijk in de sessie gemapped en bruikbaar te zijn.

Dit nieuwe gegeven leert ons dat in principe Windows/Citrix/API gewoon keurig werkt en de reader ook op een server met 70+ users goed gemapped word.
Dit leert ons dus ook dat naar alle waarschijnlijkheid de Token Adminstration tool én de activeX van de UZI/Zorginstanties op een verkeerde/andere manier de reader aanspreekt dan zou moeten zijn.

1 stap vooruit, 4 achteruit

[The End]

Koffie schreef op woensdag 18 januari 2012 @ 13:28:
Inmiddels al een topic op het Citrix forum, maar nog geen reactie.
Inmiddels zijn we wel een stap verder, maar hierdoor is het nog ingewikkelder geworden

We hebben zelf een klein tooltje geschreven wat aan de WinSCard.dll opvraagt welke readers er allemaal aanwezig zijn.
Dit werkt prima, ook in een ICA/RDP sessie krijg je keurig de doorgemapte readers te zien. Met deze tool wilde wij verder gaan troubleshooten ..
Totdat we er achter kwamen dat in een niet werkende sessie de WinSCard.dll (leeS: ons tooltje) nog steeds keurig verteld welke readers er zijn.
Dus: Daar waar de situatie zich voordoet dat er volgens ons geen reader doorgemapped word, blijkt deze wel degelijk in de sessie gemapped en bruikbaar te zijn.

Dit nieuwe gegeven leert ons dat in principe Windows/Citrix/API gewoon keurig werkt en de reader ook op een server met 70+ users goed gemapped word.
Dit leert ons dus ook dat naar alle waarschijnlijkheid de Token Adminstration tool én de activeX van de UZI/Zorginstanties op een verkeerde/andere manier de reader aanspreekt dan zou moeten zijn.

1 stap vooruit, 4 achteruit

Ik kom een dergelijk probleem ook tegen, maar dan in VMWare workstation. Soms wordt de smartcard reader niet (goed) gekoppeld aan een VM. Echter kwam ik vandaag een nieuw probleem tegen nadat ik een machine uit standby haalde. De reader werkte wel, maar de SafeSign library (Deze wordt ook door de Token Administration tool gebruikt om de kaarten te lezen) liet het afweten. Om precies te zijn: de functie 'C_GetSlotList' in de SafeSign library laat het afweten. Deze functie geeft de readers terug die in het systeem te vinden zijn (al dan niet met pas erin) en in mijn geval bleef hij zeggen dat er geen reader was, terwijl de 'normale' smartcard functies de reader en kaart wel konden benaderen. Ik vermoed dat dit exact hetzelfde probleem is als wat jij tegenkomt op de Citrix servers.

Ik heb er nog geen oplossing voor gevonden en kan het probleem ook moeilijk reproduceren. Als ik het probleem weer tegen kom, dan ga ik eens uitzoeken of ik het kan oplossen. (en dan laat ik het je weten )

[Koffie]

Hmm .. dit klinkt interessant! Heb je misschien code snippets van deze tests? Dan kan ik maandag eens kijken of dit bij mij ook het geval is.

[The End]

Koffie schreef op vrijdag 20 januari 2012 @ 17:51:
Hmm .. dit klinkt interessant! Heb je misschien code snippets van deze tests? Dan kan ik maandag eens kijken of dit bij mij ook het geval is.

Ja, wel een stukje. Mijn code wordt pas uitgevoerd nadat een smartcard in een reader is gestopt, dus ik weet zeker dat er een kaart in de reader zit en dat deze goed gelezen kan worden. Ik kan je niet alles laten zien, maar dit stukje kan je gebruiken om te kijken of er een kaart aanwezig is in de reader.

code:

#include "cryptoki.h" //onderdeel van de safesign api

HINSTANCE hDLL= NULL;
CK_FUNCTION_LIST_PTR pP11 = NULL;

long Initialize()
{
long CKRErr = 0;
CK_C_GetFunctionList pGetFunctionList = NULL;
CK_C_INITIALIZE_ARGS initArgs = { CK_NULL,CK_NULL,CK_NULL,CK_NULL,CKF_OS_LOCKING_OK,CK_NULL };

if((hDLL = LoadLibrary(_T("aetpkss1.dll"))) == NULL)  //onderdeel van de safesign api
  return GetLastError()

if((pGetFunctionList = (CK_C_GetFunctionList)GetProcAddress(hDLL,"C_GetFunctionList")) == NULL)
{
 FreeLibrary(hDLL)
 hDLL = NULL;
 return GetLastError()
}

(pGetFunctionList)(&pP11);

if((CKRErr = pP11->C_Initialize(&initArgs)) != CKR_OK)
{
 FreeLibrary(hDLL)
 hDLL = NULL;
 return CKRErr;
}

return 0;
}

long IsCardInReader(bool &CardInReaderFlag)
{
long Err = 0;
CK_ULONG SlotIDCount = 0;

CardInReaderFlag = false;

if((Err = Initialize()) != 0)
 return Err;

if((Err = pP11->C_GetSlotList(CK_TRUE,NULL,&SlotIDCount)) != CKR_OK)
{
 pP11->C_Finalize();
 FreeLibrary(hDLL)
 hDLL = NULL;
 return Err;
}

if(SlotIDCount == 0)
 CardInReaderFlag = false;
else
 CardInReaderFlag = true;

 pP11->C_Finalize();
 FreeLibrary(hDLL)
 hDLL = NULL;

return 0;   
}

Overgens zet ik de eerste parameter van C_GetSlotList op 'CK_TRUE'; dit betekent dat hij alleen de slotcount tergeeft van 'slots' waar een kaart in zit. Die zou je ook op CK_FALSE kunnen zetten om te kijken of hij wel de reader ziet.

[ Voor 11% gewijzigd door The End op 20-01-2012 19:01 ]

[Koffie]

Bedankt, ik zal er as maandag naar kijken met onze programmeur

[Koffie]

We zijn nu even aan het spelen met deze tool: http://www.idrix.fr/Root/content/category/5/23/40/
We laden dan AETPKSS1.DLL om deze vervolgens te initialiseren.
Doen we dit in een sessie op een drukke server (waarbij we dus in de token beheer tool géén readers zien) krijgen we de foutmelding "Error CKR_FUNCTION_FAILED while getting slots".
Op een server waar we de readers in de token beheer tool wél zien, krijgen we die foutmelding niet maar zien we de 10 virtuele slots.

=[edit]=
Onderstaande log is van een niet-werkende situatie:

15:01:30: C_Initialize(0x00000000)
15:01:31: C_Initialize returned No error

15:01:31: C_GetSlotList(FALSE, 0x00000000, 1242736)
15:01:31: C_GetSlotList returned CKR_FUNCTION_FAILED

15:01:31: C_GetInfo(0x0012F720)
15:01:31: Output :
	Manifacturer : A.E.T. Europe B.V.              
	Description : Cryptographic Token Interface   
	Cryptoki version = 2.20
	Library version = 3.00
15:01:31: C_GetInfo returned No error

15:01:31: C_WaitForSlotEvent called in blocking mode
15:01:31: C_WaitForSlotEvent returned error CKR_FUNCTION_FAILED
	stopping slots listening thread

[ Voor 40% gewijzigd door Koffie op 23-01-2012 15:15 ]

[The End]

15:01:31: C_GetSlotList(FALSE, 0x00000000, 1242736)
15:01:31: C_GetSlotList returned CKR_FUNCTION_FAILED

Dit kan twee oorzaken hebben. De makers van die tool hebben de laatste waarde (de CK_ULONG SlotIDCount = 0; uit mijn code niet op 0 geinitialiseerd; daarom staat daar nu een random waarde. Misschien mislukt de fuctie daarom. Bij mij mislukte die functie niet, maar gaf hij terug dat er geen readers met kaarten aanwezig waren, terwijl de Windows SCard functies wel konden communiceren met de kaart.

Echter denk ik dat er toch wat fout lijkt te gaan in de AETPKSS1 dll. Kan je zien hoeveel sessies met kaart er aanwezig zijn op de Citrix server op het moment als het fout gaat? Misschien overschrijd je het aantal readers dat de dll aankan.

Ik ga even zoeken wat de laatste versie is van de AET Crypto api. Misschien dat het al gefixed is.

[Koffie]

The End schreef op maandag 23 januari 2012 @ 19:34:

15:01:31: C_GetSlotList(FALSE, 0x00000000, 1242736)
15:01:31: C_GetSlotList returned CKR_FUNCTION_FAILED

Dit kan twee oorzaken hebben. De makers van die tool hebben de laatste waarde (de CK_ULONG SlotIDCount = 0; uit mijn code niet op 0 geinitialiseerd; daarom staat daar nu een random waarde. Misschien mislukt de fuctie daarom. Bij mij mislukte die functie niet, maar gaf hij terug dat er geen readers met kaarten aanwezig waren, terwijl de Windows SCard functies wel konden communiceren met de kaart.

De log output is dus niet gebasseerd op jou code, maar komt uit http://www.idrix.fr/Root/content/category/5/23/40/
We kunnen reproduceren dat we die foutcode krijgen (namelijk als de SafeSign tool 'm ook niet ziet) of dat we succes krijgen (op een rustige server met werkde SafeSign).

Echter denk ik dat er toch wat fout lijkt te gaan in de AETPKSS1 dll. Kan je zien hoeveel sessies met kaart er aanwezig zijn op de Citrix server op het moment als het fout gaat? Misschien overschrijd je het aantal readers dat de dll aankan.

Was het maar zo'n feest
Ik zou hooguit nog kunnen zoeken (met deze nieuwe info) op het gebruik van VDSCARDN.DLL als client module. Grootste probleem is, dat ik (voor zover ik weet) iig niet met MFCOM makkelijk kan detecteren of die client module geladen is.
Hooguit kunnen we nog met ons eerste script aan de gang gaan en loggen, maar dan weten we nog niets van die AETPKSS1.DLL, intern kon die persoon niet veel met jou code (hebben we eerst die SDK nodig? Hij had het erover dat hij die cryptoki.h niet had).

Ik ga even zoeken wat de laatste versie is van de AET Crypto api. Misschien dat het al gefixed is.

Thanks

Inmiddels ook alle technische info al bij AET Europe gelegd (donderdag de eerste mail) maar nog geen response gehad.

Ik ben het wel met je eens dat het waarschijnlijk in een x aantal gekoppelde readers gezocht moet worden (then again: de AETPKSS1.DLL laad de slots pas als er om gevraagd word )

[Verwijderd]

Koffie schreef op maandag 23 januari 2012 @ 21:57:
[...]

De log output is dus niet gebasseerd op jou code, maar komt uit http://www.idrix.fr/Root/content/category/5/23/40/
We kunnen reproduceren dat we die foutcode krijgen (namelijk als de SafeSign tool 'm ook niet ziet) of dat we succes krijgen (op een rustige server met werkde SafeSign).


[...]

Was het maar zo'n feest
Ik zou hooguit nog kunnen zoeken (met deze nieuwe info) op het gebruik van VDSCARDN.DLL als client module. Grootste probleem is, dat ik (voor zover ik weet) iig niet met MFCOM makkelijk kan detecteren of die client module geladen is.
Hooguit kunnen we nog met ons eerste script aan de gang gaan en loggen, maar dan weten we nog niets van die AETPKSS1.DLL, intern kon die persoon niet veel met jou code (hebben we eerst die SDK nodig? Hij had het erover dat hij die cryptoki.h niet had).

[...]

Thanks

Inmiddels ook alle technische info al bij AET Europe gelegd (donderdag de eerste mail) maar nog geen response gehad.

Ik ben het wel met je eens dat het waarschijnlijk in een x aantal gekoppelde readers gezocht moet worden (then again: de AETPKSS1.DLL laad de slots pas als er om gevraagd word )

Misschien ver gezocht, ik weet niet hoe jou login/logoff en reboot gedrag is van de Citrix server, maar zou het niet mogelijk zijn dat als iemand de sessie start hij een slot in gebruik neemt, maar bij het uitloggen niet vrijgeeft?

Hierdoor zou het kunnen dat zoals hierboven al is aangegeven de slots op ten duur op zouden zijn...of overbelast oid?

[Koffie]

Dit is nu een beetje de hoek waarin we het zoeken.
Inmiddels hebben we het e.e.a. zelf geschreven voor logging in een DB.
Wanneer een user inlogd, doen we twee tests:
1) zien we met WinSCard.DLL een reader?
2) kunnen we via AETPKSS1.DLL een C_GetSlotList aanroepen?

Zoals het er nu naar uitziet, krijgen we totaal random errors op de C_GetSlotList functie (of we krijgen netjes de slots, of we krijgen error 6 "CKR_FUNCTION_FAILED").

Probleem is dat we ook totaal geen trend zien in wanneer error code 6 als antwoord komt. Op de ene server kan ik de hele dag 25 man met readers hebben, terwijl ik zojuist een andere (lege) server in de productie pool gooi en al bij de 11e concurrent user geen slots meer krijg.

[The End]

Koffie schreef op donderdag 26 januari 2012 @ 15:38:
Dit is nu een beetje de hoek waarin we het zoeken.
Inmiddels hebben we het e.e.a. zelf geschreven voor logging in een DB.
Wanneer een user inlogd, doen we twee tests:
1) zien we met WinSCard.DLL een reader?
2) kunnen we via AETPKSS1.DLL een C_GetSlotList aanroepen?

Zoals het er nu naar uitziet, krijgen we totaal random errors op de C_GetSlotList functie (of we krijgen netjes de slots, of we krijgen error 6 "CKR_FUNCTION_FAILED").

Probleem is dat we ook totaal geen trend zien in wanneer error code 6 als antwoord komt. Op de ene server kan ik de hele dag 25 man met readers hebben, terwijl ik zojuist een andere (lege) server in de productie pool gooi en al bij de 11e concurrent user geen slots meer krijg.

Ik ben ook even verder gegaan met testen. De functie C_GetSlotList van de AET library is gewoon niet helemaal lekker. Eens in de zoveel tijd krijg ik het voor elkaar dat deze functie een crash veroorzaakt, terwijl ik 100% zeker weet dat de input van de functie goed is.

Ik ben het probleem waar jij tegenaan loopt in de tussentijd niet meer tegengekomen. Dat kan echter ook komen, omdat ik nu test met maar een reader.

[Koffie]

Als jouw functie crashed, krijg je dan ook error 6 (CKR_FUNCTION_FAILED) terug?

[The End]

Koffie schreef op vrijdag 27 januari 2012 @ 10:53:
Als jouw functie crashed, krijg je dan ook error 6 (CKR_FUNCTION_FAILED) terug?

Nee, dan crashed de applicatie in de functie. De returncode kan je dan niet meer zien, omdat het programma direct beeindigt.

[Koffie]

Ah OK.
Wij krijgen, net als in de logfile die ik eerder gepost had, errorcode 6 terug van de DLL

[Koffie]

Enorme rotschop

Gisteren hebben wij de laatste final van SafeSing geinstalleerd (SafeSign-Identity-Client-3.0.70-std-general-x64_admin) nadat een eerdere RC al de oplossing gaf.
Na ruim een jaar troubleshooten en uitgebreid contact met A.E.T. en CIBG Ministerie van Volksgezondheid, welzijn en sport hebben we de oplossing gevonden

Uiteindelijk bleek dat errorcorde 6 optreed op het moment dat het SessionID van de user hoger is dan 31 Ongeacht het aantal gebruikers op de server.
Situatie: er zitten 50 gebruikers ingelogd 1 server. Een nieuwe gebruik logt in en krijgt SessionID 51. Gevolg: Errorcode 6. Vervolgens logt een gebruiker die SessionID 10 heeft uit. Weer komt er een nieuwe gebruiker. Deze krijgt de eerder vrijgekomen SessionID 10 toegwezen. Gevolg: werkende UZI pas.

Deze bevindingen hebben wij aan A.E.T. teruggekoppeld welke vervolgens een nieuwe versie geschreven heeft. Zoals gezegd werkte de eerste RC meteen prima, waarna deze final gemaakt is.

[The End]

Dat is goed nieuws! Is deze versie al te krijgen of is deze speciaal voor jullie gemaakt?

Ik had het probleem van de crashende SafeSign library trouwens opgelost door steeds de library opnieuw te laden. Dit leek het probleem bij mij op te lossen.

[Koffie]

Ik ga er vanuit dat dit een gewoon te verkrijgen versie zal zijn/worden.
Wel hebben wij de releases rechtstreeks gekregen, dus ik weet niet of ze al vrij te downloaden zijn.

[Blabla13]

Ik heb ook het topic met veel interesse gelezen. (kwam er redelijk toevallig op).
Wellicht dat ik eenzelfde probleem heb, ook al lijkt het er hier op dat het ook nog aan een type terminal kan liggen. (hierover heb ik nog geen terugkoppeling ontvangen door de gebruikers.)
Ik hou die volgende versie wel in de gaten, zodra deze beschikbaar komt. Dat zal hopelijk vlot zijn, want zo te horen zijn er genoeg mensen die tegen deze bug aanlopen.