[8.174][BUG][FIXED] How to get AAA client to encrypt password

Might be a silly question, but did you download the new client from WebAdmin, or just reinstall from a previous version?

Always best to ask the obvious... it wouldn't be the first time it bit me in the @$$.

Yes, I did download a new version... even cleared the browser cache to make sure it wasn't giving me a cached version.  I'm thinking windows XP again.... I have to convince the better half that we need to upgrade all the workstations to Win 7.

In the next few days, I'll dig around for some old XP install media and bring up a VM to see if I can experience the same issues that you're seeing with AAA.

That would be awesome.  XP is still going strong.... my company uses it still.

Thanks,
Scott

Ok, after an absolute nightmare time getting an XP VM installed (if you don't keep focus on the VM console during install, it will hang at the device install portion), then installing 87 googolplex windows updates, here's what I found.

With WinXP Pro 32-bit,  I can replicate this bug.  On this OS, the Password string value in HKEY_CURRENT_USER\Software\Astaro\Astaro Authentication Client\ is not encrypted and is still displayed in plain text.

This also leads to another bug with AAA in XP.  Because the value is not encrypted, but AAA.exe is expecting it to be, AAA.exe doesn't/can't pre-populate the password for set credentials if the client is restarted.  Every time the client is restarted, the password needs to be entered again.

Here's my analysis on why this is happening.  I could be far off on this, but it's what it looks like to me given the information available.  Looking at the value in Vista and Win7, it appears that part of the encryption process is converting the password characters to an asian character set.  In Vista and Win7, all languages are available to the OS by default.  In WinXP (2003 and 2000 also), only the default language is available, so the language translation portion of the encryption process fails.

Scott, could you also install IPv6 stack on XP (that's the easy part)....  then you need Dibbler to be able to install an IPv6 DHCP client on XP otherwise it can only use announcements to get an IP.  I'm hoping you can replicate my other issue which is in another thread called https://community.sophos.com/products/unified-threat-management/astaroorg/f/110/t/71009 .

I to noticed that it isn't storing the password.

Thanks Scott.

Paul

Probably due to my unfamiliarity with Dibbler, but I can't get a DHCPv6 address at all currently on XP.  I'll have to get that solved first.  [:)]

Gave up on dibbler and just manually assigned an IPV6 address.  [:)]  I'll post the results in your other thread.

AAA and proxy authentication for ipv6 usage appears to have several big issues.  Hopefully this thread and the other get another going over by Kai.  These could potentially generate a ton of support requests post 8.200GA, so they need to get on the roadmap for 8.201.

Here's my analysis on why this is happening.  I could be far off on this, but...

As far as i can see from the code, there's no foreign-language-thing happening at all.

But there's a check build in, which tries to find out whether the password has been stored encrypted or unencrypted in the registry. If there's an unencrypted password, it will be taken as is.

So, if there's a brave soul out there to try this:

• uninstall the client
  
• manually remove that registry entry
  
• reinstall and retry
  

Cheers,
Kai