Wednesday, June 16, 2010

Restore encrypted files with iFolder 3.8

This is a pain in the ass! It doesn't seem there is any support for this in iFolder. If you copy a file back to its original location on the iFolder server, the user can not sync it back. I guess this is because all information on what to sync is in the simias database.

However, I found a way to restore single files. But this didn't work if the entire iFolder was deleted.

Send the restored encrypted file to the user. Tell the user to add it in the original folder location and force a sync. This will make the file double encrypted on the iFolder server. After the sync is complete. Tell the user to revert the iFolder to normal folder. Replace the double encrypted file on the iFolder server with the restored encrypted file. Then tell the user to download the folder to a new location. The encrypted file will now be decrypted on the client.

Now the user have to fix up the mess with two different folders with almost the same content.

I hope there will be some kind of fix for this in a future version of iFolder.

iFolder 3.8 and Active Directory

I finaly got iFolder to work with Active Directory! :)

All you need to do is answer yes on LDAP in the simias-server-setup and write in all the DN information for the admin and proxy user. I made the users in AD before I ran the setup. You can get the DN information from AD with adsiedit.msc on your domain controller. Right click the user or OU you want the information from and click properties. Scroll down to distinguishedName, double click it, and copy the value.

One question you will encounter in the simias-server-setup is the LDAP group support. Because it need to change the AD schema, I chose not to do it at the beginning. At a later point I found out that you get some benefits with the LDAP group support without extending AD schema. Make sure the proxy user is not a member of schema administrators if you don't want to extend the schema.

The benefits with LDAP group support is that you can put groups in the search context instead of just OUs. I find this very useful because it's much simpler to control who gets access to iFolder. However, to add more that one search context, I had to edit the Simias.conf file and add a new line:
<context dn="CN=ifolder-group,OU=Groups,OU=Company,DC=example,DC=com">
<context dn="CN=ifolder-group2,OU=Groups,OU=Company,DC=example,DC=com">
I used sAMAccountName insted of cn or email for the NamingAttribute. Works like a charm. Now the users can use their usual username to login to iFolder.

I did another change in the Simias.conf file. I change the "LdapSyncOnRestart" value to "yes". Default, the LDAP sync is every 24 hours. You can change this on the admin web as soon as you can log in. You can also force a sync here. I do not know how to force a sync from command line. I had problems logging in to the admin web before I changed this.

Remember to restart apache after doing changes in the Simias.conf file

Useful logs:
I used this alot when I experimented with DN. You will see error messages here if you have wrong format in your search context. You also see the sync information. You need to turn the logging to debug to see more information. This can be done from the admin web.

Log for admin web. You'll find information about logins to the admin web.

Friday, June 11, 2010

Changing password on iFolder 3.8 without LDAP

I ran into a problem when trying to change the admin password on my iFolder 3.8 installation. It didn't work to run simias-server-setup again. The old password was still active.

This is how did it:
/usr/bin/mono /usr/lib/simias/bin/UserCmd.exe setpwd --url http://localhost --admin-name admin --admin-password (current password) --user admin --password (new password)

on 64-bit OS, the "lib" folder is "lib64"

You can use this to change users password too:
/usr/bin/mono /usr/lib/simias/bin/UserCmd.exe setpwd --url http://localhost --admin-name admin --admin-password (admin password) --user (username) --password (new user password)

Thank you Jeremy :)

A little update on this. You can also add and delete users with this tool. Use delete or create, instead of setpwd.

Thursday, June 10, 2010

Fortigate SCP backup

Here is a small guide to backup Fortigate config with SCP

Using the Web-based manager:
Go to System > Admin > Settings.
Make sure SCP is enabled

Go to System > Network > Interface.
Select the Edit icon for the interface you use for administrative access.
In the Administrative Access section, select the SSH check box.
Click OK.

Create a public-private key pair using a key generator tool compatible with your SCP client.
root@linux:~# ssh-keygen -t rsa -b 2048 -f /tmp/fw-001
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): ENTER
Enter same passphrase again: ENTER
Your identification has been saved in /tmp/fw-001.
Your public key has been saved in /tmp/

Save the private key to the location on your computer where your SSH private keys are stored.
root@linux:~# mv /tmp/ /etc/
root@linux:~# mv /tmp/fw-001 /etc/fw-001.sec

Connect to the fortigate using SSH.
root@linux:~# ssh admin@x.x.x.x

config system admin
edit admin
set ssh-public-key1 "[paste content from /etc/]"

And you are done! :)

To trigger the copy, run the following command from bash.
root@linux:~# scp -i /etc/fw-001.sec admin@x.x.x.x:sys_config /backup/fw-001.fg.bin

You can also set up CVS to get config revisions.

Wednesday, June 9, 2010

iFolder 3.8 on OpenSuse 11.1

I've actually never been much of a Linux gnome, but since iFolder server is only available on Linux I did not have much choice here. I chose to use OpenSuse (mostly because my boss insisted on it). The OpenSuse installer is almost like any windows application; next - next - next - finish :)

I used 32-bit OpenSuse 11.1 with KDE
I used this blog post as a reference for my configuration.

I had alot of problems during the installation of iFolder, most of them because of wrong version of dependencies for iFolder i think, but with the iFolder repository mentioned below, most went well. At first I used OpenSuse 11.2, but jumped back a version because of all the problems I had. Now that I know the cause of the major problem I had, I don't think it's a problem to use OpenSuse 11.2.

Because of my lack of Linux knowledge, I used Yast2 to get all the packages for iFolder. I used this repository. (I guess it's just to change the link to 11.2 to make it work on OpenSuse 11.2).

Open Yast2 and add the following packages:
- Yast2-http
- ifolder3-enterprise
- novell-ifolder-enterprise-plugins
(I think the rest follows as dependencies, but do a search and check if they're added)
- mono-core
- xsp
- apache2
- apache2-mod_mono
There are a few other dependencies too.

WARNING!!! The next step is what caused me about 15 hours scratching my head! USE SSL! I had weird problems when not using SSL (got a .NET error when navigating to the system tab in iFolder administration page).

When this is complete, generate a SSL certificate by using the command gensslcert in a terminal window.

Open Yast2 and search for http server, run the configuration wizard with all the default settings (open the firewall ports 80 and 443 if you have the firewall turned on).
Open Yast2 (again) and enter the http server configuration. Go to the server module tab and enable SSL.

Copy the SSL template to the apache configuration:
cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf

restart apache2:
service apache2 restart

Okay! Now we are ready for the iFolder setup!
I used most of the default settings, except for SSL. When you get that option, write BOTH.
I did not use LDAP (I will at a later time).
Another important option is to configure Apache2. Select YES on that one.

Now, this is where I made a mistake. When the configuration is done, you'll probably get an error with the certificate. RUN THE simias-server-setup AGAIN! Do exacly the same as you did before and everything works fine. Don't ask me why. I continued my installation without SSL because of this, and that caused the weird problem I described in the beginning of this article.

Run ifolder-admin-setup
I used all the default settings here.

Run ifolder-web-setup
I used all the default settings here.

restart apache 2 again:
service apache2 restart

Congrats! You now have iFolder! :D

Use https://IP-address/admin/ to administrate iFolder. It's very easy.
The clients can use https://IP-address/ifolder/ to access their files without the ifolder client.

Thank you a million times Milko, for this post. This helped me figure out the problem with the system tab on the iFolder administration page.

I'm listing some problems I've also had during this setup:
Q: Can't login to admin web console (wrong username and password)
A1: no permission to the data folder. chown -R wwwrun:www /path/to/data/folder
A2: I ran into a bug in the simias-server-setup. The first character seemed to get ignored every time I tried to change the data folder. To "solve" this, I pressed backspace alot of times, then entered the path to the data folder.It seemed to be hidden letters there. Same thing happed on other settings too sometimes.

Q: SSL error when running simias-server-setup with SSL [Y]
A: This is what I mentioned above. You have to run the simias-server-setup twice with the SSL setup

Q: I also ran into a problem with the SSL certificate during ifolder-admin-setup
A: regenerated the SSL certificate with gensslcert and reran the ifolder-admin-setup

I've read that iFolder on OpenSuse 11.2 can have problems if you don't do this:
chown wwwrun:www /var/lib/wwwrun

Frequent account lockout

I have had a problem with an account in our domain for some time. It got locked out about once per hour after a password change. It turned out to be used as DNS dynamic update on the DHCP scope.

To identify what Domain Controller the lockout came from. I used altools from Microsoft.

Just start lockoutstatus.exe, and enter the username. This will give you a list of all the Domain Controllers and where the lockout originated from. Take a notice on the time stamp on when it happened, and log in to that particular Domain Controller. Head for the security log and find the time stamp you found in the account lockout tool. The failure code tells you why it failed (0x18 I think is wrong username or password). You will also find the IP address of the culprit.

This is where my problem started. The IP address I found in this security entry was I could not find anything on the server that was the reason for locking out that account, so I started to look for viruses... nada. Until I FINALY come over a post that described the same issue. That damn DHCP scope DNS dynamic update credentials thing.

Well, well. It's solved now. I am happy :)

Some other reasons that can cause account lockouts:
- schedual task
- services
- disconnected RDP/Citrix session
- other 3rd party software with hardcoded credentials

btw... I also tried the alockout.dll from altools. It didn't give me any information on this issue. I don't think it is possible to find anything in any logs.

Me, blog!?? Hell no!

Well, okay.... yes. I finally thought it was about time to share my knowledge to the word :) I basicly work as a network consultant, but do alot of other things around computers and servers. When I work on a complex problem, i tend to goolge to find my answers, and most answers, guess what!? I find on blogs and forums! :) Then why not help others in need? I have a few topics I want to start with, so... yeah :)

btw... I don't think this will be a complete technical nerdy blog. I'll try add some other stuff too :)