iPad/iPhone Tester Application - Authentication Error - Workaround

[Courtney Lindsey]

All,

I've been working with Roger Moffatt on identifying an Authentication
Error received when using the iPad/iPhone Tester Application. As a
side note,I haven't tried the non-tester one yet or the beta client
but will soon as we're able to get the tester application to function
now.

After a lot of reverse engineering of the iFolder base I stumbled upon
a workaround. I do believe that those who use LDAP for their user
provisioning will not run into this issue but for those that don't,
this workaround should work for you.

First, the testing iFolder environment I'm using is based upon the
instructions here:

http://www.daniellench.com/2010/08/ifolder-on-opensuse-11-3/

That is what I used to setup and configure the environment prior to
testing, OpenSUSE 11.3 using the 1-Click install option for the
iFolder Server. Also, as you've already guessed, the testing
environment doesn't use any type of LDAP service relying exclusively
on the local store for authentication and user provisioning.

To get straight to the fix, you simple have to configure the iFolder
server to use the LDAP authentication method versus the built in
simplified one. Although you're not using LDAP, the method in which
it identifies/authenticates the users is what allows the iPad/iPhone
Tester Application to access the data.

Do the following to change a system from the simplified identification/
authentication method to the LDAP identification/authentication
method. (Assumption right now is you used the default store location
for iFolder so change as needed.)

Copy the LDAP authentication module from the simias source:
# cp /etc/simias/bill/modules/IdentityManagement.conf /var/lib/simias/
modules/IdentityManagement.conf

Change ownership of the module files to make sure they're owned by the
Apache account:
# chown -R wwwrun:www /var/lib/simias/modules

Restart the Apache service to reload:
# su -
# rcapache2 restart

That's it! You should now be able to successfully test out the iPad/
iPhone Tester Application. Now, before you leave this post to go try
it out you should note this will change at least one administrative
behavior.

The system is now using the 'IdentityManagement.conf' configuration so
it thinks your provisioning of users is all coming through the LDAP
service. Unfortunately what this does is remove the user 'Create'
option on the iFolder admin website interface. The good news is you
can still use the command line option to manage the user base or go
back and forth on removing and re-adding the 'IdentityManagement.conf'
file. I prefer to not continuously restart the Apache service so am
using the command line interface.

Example command to add a user. (for a complete list of options type
'# mono UserCmd.exe --help')
# cd /usr/lib/simias/bin
# mono UserCmd.exe create --url http://localhost --user John --
password <password> --first John --last Doe --full "John Doe" --admin-
name admin --admin-password novell

I hope this helps those having authentication issues when not using an
LDAP environment. I plan on testing an LDAP configuration to verify
my results but for now this should get you up and going.

Thanks

Court

[Roger Moffatt]

Thanks for the fantastic post. I can confirm this works for a fresh install, although in my case I had to copy the file to /var/simias/data/simias/modules. Brilliant!

I'll see if we can get some assistance from Novell to resolve this in a slightly neater way!

[Courtney Lindsey]

Just to give everyone an update. I tested setting up a OpenLDAP
server in a standalone setup on the same server I have iFolder running
on. I was able to confirm that I did not run into the same
authentication issue experienced with the non-LDAP setup.

Thanks

Court

[Trever Jackson]

This option isn't working for me. Resetting apache doesn't seem to do
anything to the config. I had to manually create the simias the
modules directories under /var, is the same as what you had to do?




On Mar 23, 10:37 am, Courtney Lindsey <courtney.lind...@gmail.com>
wrote:

> # mono UserCmd.exe create --urlhttp://localhost--user John --

[Trever Jackson]

Nevermind.. Roger's suggestion fixed it.

On Mar 23, 10:37 am, Courtney Lindsey <courtney.lind...@gmail.com>
wrote:

> # mono UserCmd.exe create --urlhttp://localhost--user John --

[Christopher Karopoulos]

We have tried your workaround on a fresh Novell OES2 sp3 standard install of iFolder 3.8.4 and it does not seem to fix the issue. In fact it breaks the login to the iFolder administration page also....
Basically we did the following:

cp /opt/novell/ifolder3/etc/simias/bill/modules/IdentityManagement.conf /var/simias/data/simias/modules/IdentityManagement.conf
chown wwwrun:www /var/simias/data/simias/modules/IdentityManagement.conf
rcapache2 restart

Even tried restarting the whole server but no cigar....

I have taken a look at an OES2 sp2 setup elsewhere that is working perfectly and the IdentityManagement.conf already exists in /var/simias/data/simias/modules. Have you heard anything back from Novell? It looks alot like an installation bug on their part from where I stand.

[Roger Moffatt]

Novell continue not to respond unfortunately :(

I've spent the day with some fresh virtual servers running OpenSuse 11.3 and iFolder 3.8.4 and there's something really odd. The issue has been 100% reproducible all day. Fresh install, create 1 new user, try to access https:<fqdn>/simias10/iFolderWeb.asmx and no dice. 

Known facts:

1) the admin account can always login

2) a real unknown account always fails correctly with "fred is not a member of simias" in the debug level logs

3) the real known account (which works for client and web access) always fails incorrectly with "??? is not a member of simias"

4) I now think SSL is a red-herring. The same behaviour happens if you do a NON-SSL install.

5) If you create accounts using mono usercmd.exe, they DO work.

And most bizarre of all

6) Somewhere in my test cycle of putting the IdentityManagement.conf file in place, restarting, running tests, removing the IdentityManagement file and so on, it now seems to have stuck in a mode WHERE IT WORKS. I believe the trigger for this was the first time I created an account using mono usercmd.exe.

7) Also, I note that when I use mono usercmd.exe list to view the list of users. Instead of getting all my new test users, it only lists the first user account I created which didn't work and STILL doesn't work.

However I can now create users using the command line tool AND the admin interface, so the system is working as expected. Apart from my poor first test user who only works when I put the IdentityManagement.conf file in place. With the file in place, ALL the users can login. Without it, only the ones either created using usercmd.exe OR the ones created since it all started to work.

I'm documenting it all here in case any of this resonates with someone else. I now need to rewind and build some new test cycles to see exactly what the trigger is for it working.

All very odd. 

[VLA]

Hi all,

Further to your Roger's findings, please find my experiences:

a) Fresh install of Novell OES SP2 (which is SLES 10.3 and OES SP3), iFolder 3.8.4 and its dependencies (such as eDIR, Remote Manager etc).  I also installed the option of iManager so I could add users into the eDIR.  Accepted all installation defaults for iFolder.  Created a new eDIR tree with appropriate O and OU structures.

b) Confirmed that eDIR is accessible, unchecked TLS requirement for the LDAP group in eDIR and confirmed that I could browse the tree using a third party LDAP browser.  All working kewl.

c) Confirmed that I could login the https://<host>/admin.  Selected the server and set up the "Identity Sync" to 30 minutes and "Grace Interval" to 60 minutes.  Configured the "LDAP Contexts" to include an additional (users) OU.

d) Added two test users to the "eDIR users OU" and selected "Sync Now".  Users sync'd as designed (appeared in the list of users).

e) Tested access to https://<host>/ifolder using the test user accounts.  All working kewl.

f) Added a test user as an administrator - successfully logged into the Admin portal.  I note from the log (/var/simias/data/simias/log/Simias.log) the following lines . . .

2011-04-27 08:06:05,298 [-1229927520] INFO  Simias.Server.Authentication - Authenticated User iS : 1cb8815a-2d43-441e-b6db-b8949df0d926:Admin Success
2011-04-27 08:06:05,378 [-1237656672] INFO  Simias.Server.Authentication - Authenticated User iS : 1cb8815a-2d43-441e-b6db-b8949df0d926:Admin Success
2011-04-27 08:06:05,466 [-1282331744] INFO  Simias.Server.Authentication - Authenticated User iS : 1cb8815a-2d43-441e-b6db-b8949df0d926:Admin Success

g) I try to list all the users using UserCmd.exe I note in the /var/simias/data/simias/log/Simias.log the following . . .

2011-04-27 08:37:20,861 [-1286603872] ERROR Simias.LdapProvider.User - LdapError:NDS error: failed authentication (-669)
2011-04-27 08:37:20,861 [-1286603872] ERROR Simias.LdapProvider.User - Error:Invalid Credentials
2011-04-27 08:37:20,861 [-1286603872] ERROR Simias.LdapProvider.User - DN:cn=Admin,ou=IT,o=IFLDR
2011-04-27 08:37:20,909 [-1286603872] INFO  Simias.Server.Authentication - InvalidCredentials : admin

h) I try the following site http://<host>/simias10/iFolderWeb.asmx and I receive the same error in the log . . .

2011-04-27 08:39:52,974 [-1281262688] ERROR Simias.LdapProvider.User - LdapError:NDS error: failed authentication (-669)
2011-04-27 08:39:52,975 [-1281262688] ERROR Simias.LdapProvider.User - Error:Invalid Credentials
2011-04-27 08:39:52,975 [-1281262688] ERROR Simias.LdapProvider.User - DN:cn=Admin,ou=IT,o=IFLDR
2011-04-27 08:39:53,043 [-1281262688] INFO  Simias.Server.Authentication - InvalidCredentials : admin

i) I then change the LDAP source, LDAP contexts to an existing eDIR tree and sync the users . . . LO-AND-BEHOLD!!!!  Everything works as designed.

I'm on the mission now to look at the differences between the two eDIR trees.  I suspect it's a "Universal Password" option in a password policy.