LDAP support

Hi,

 We had the LDAP authentication previously in use, without that much issues.

 Now we installed the 1.0.0.1093, and when opening up the system we get the initial welcome page: "

Getting Started

Before you can use Continua you will need to create a new Administrator User Account, if this is the first time you have used Continua then click Next to be guided through some basic configuration.
"

 So apparently the Continua lost the LDAP configuration and is unable to migrate the settings.

From where should we should start to resolve the issue?

 

Apparently the reason was that the LDAP configuration was excised from the .config -file.

However now when the LDAP config data was restored to the file (fdqn, administratorsGroup) the system does not allow logging in, but states
" The page you requested required permissions that you do not have, you can choose to login with an account that has the necessary permissions or go home. "

The account is the same I’ve been used previously and should be in the specified admin group. We’re bit at a loss as to how to resolve the issue.

Hi Olli

The ldap element was renamed to authentication, the installer should have taken care of that. If you have a look in the installation folder, there should be a config file with a .new extension. The installer always installs this file, then copies the settings from the original config (if it exists) and then copies the .new file over the original .config file (the idea is to be able take new settings but still preserve the changes made by you during install).

This is what the authentication element should look like :

[code] <authentication mode=“LDAP” fqdn=“your.domain.name” administratorsGroup=“your continua admin group” groupsContainer="" /> [/code]

Do you know what build you upgraded from, I’d like to test the upgrade and see what the installer is doing.

It would appear that the all traces of the previous LDAP config were excised by the installer. There were the authentication -element in the configuration, but it was the default one (using Forms) authentication.

The upgrade was carried out from previous build, but I cannot say if the previous one was ever actually used after being installed.

Now the issue is the fact that despite reconstructing the LDAP authentication information to the configuration I’m not able to log in due to the error in my second message, and we’re bit lost as how to resolve the issue.

Investigating the issue directly from the database it would appear that there is some issues in synching with the AD. The following entry is recorded in the core_events -table on each service restart:
“Could not synchronize with Ldap domain ‘.com’ and groups container . While trying to resolve a cross-store reference, the target principal could not be found in the domain indicated by the principal’s SID.
Synchronization will be attempted again in 30 minutes.”

Hmm… this looks like something we should be handling, will investigate.

 

I entered a groups container information to the configuration file, and now the situation is that there appears no new items in the database event log, but the login is still not possible - "The page you requested required permissions that you do not have, you can choose to login with an account that has the necessary permissions or go home."

We really need to get this resolved ASAP.

I’m thinking there is perhaps something wrong with the IIS configuration. In IIS Admin, check that the authentication for the website is set to Forms enabled and Windows Authentication disabled. There should also be a WindowsAuthentication child application under the site, it should have Windows Authentication enabled and Forms disabled.

Alternatively, uninstall Continua CI (and delete the website in IIS), not sure which db server you are using, if it’s postgresql the installer will detect the previous db and ask if you want to use it. Many of the issues with the installer seem to be coming from trying to upgrade prior beta installs. If you are able to provide remote access to the server we can login and see what is going on (contact support@finalbuilder.com if you want to do that).

Hi Ollie,

The event log message states that the domain that it is trying the synchronise with is “.com”. Can you check that the ‘fqdn’ attribute on the authentication node in Continua.Server.Service.exe.config is a correct domain? The ‘groupContainer’ attribute is optional and can be left empty. However ‘administratorsGroup’ is important, you must have at least one admin user in this group in Active Directory. You should try logging as a user in the group first if you are still getting issues with permissions.

[code]<authentication mode=“LDAP” fqdn=“office.company.local” administratorsGroup=“Continua Administrators” />[/code]

Although this will not help you now, we have updated the installer today to ensure that ldap attributes are copied correctly from the old configuration file to the new one. A new build will be made available soon with this change.

Note that the installer should have backed up the old file to Continua.Server.Service.exe.config.bak although subsequent installs will have overwritten it.

Unfortunately the IIS configuration was correct (Anonymous and Forms for the web site, and Windows for the Application).

I already tried to install the current build (1100) with re-specifying the settings, but without success.

If nothing else comes up, I’ll try to remove the installation and re-install.

If I had to guess there is either something still wrong with the LDAP sync or with the data in the database concerning the users and their rights.

The event log had the correct domain name which I tried to replace with generic placeholder, which didn't go thru with the forum software.

I’m just going through the ldap sync now… looking at how we can improve the error reporting so we can see where it is failing.

Hi Olli

I have uploaded build 1102, which will log the ldap exception to the windows eventlog with a stack trace, hopefully that will help us pinpoint where the error is occurring. 

32-bit Continua Server Installer

64-bit Continua Server Installer


Hi,

 The links in your post were for the build 1100, but I was able to download the build 1102.

However I failed to find where the logging you referred to would be located.

Sorry, I shouldn’t post late at night after a long day! There should be an entry in the windows eventlog.

Hi,

 I tested this again now, and restested it also after restarting the service.

 No entries concerning my login attempt was logged to the Windows Event Log.

There is also no new items in the Continua event log.

Ok, I will talk to Dave when I get into the office later and we’ll see what we can do to figure this out.

Just to add a +1 to the installer issues - we upgraded to 1093 from the build directly before it, and now have no authentication elements in the config file (.bak, .new or .config). We were previously using the ‘original’ way to configure ldap via Windows Authentication in IIS.

I should add that all the ldap groups and users still show up in Continua, but we get the same error logging in as Olli - " The page you requested required permissions that you do not have, you can choose to login with an account that has the necessary permissions or go home. "

Hi,

 I tested now reinstalling the build 1102, but unfortunately without much success.

For reference the LDAP -configuration element in old configuration was apparently

<ldap enabled="true" fqdn="ourdomain.com" administratorsGroup="build_admins" />

and that configuration worked without issues.

Now when I re-installed the Continua there were number of different stages where I tested this.

1) Initial stage after installation had the authentication -key in the configuration as

<authentication mode="LDAP" fqdn="ourdomain.com" administratorsGroup="Build_Admins" groupsContainer=""/>

When the service started an exception was outputted to the event log:

Could not synchronize with Ldap domain 'qpr.com' and groups container . Getting all ldap groups
Sync status : While trying to resolve a cross-store reference, the target principal could not be found in the domain indicated by the principal's SID.
Synchronization will be attempted again in 30 minutes.
 Stack Trace :
   at System.DirectoryServices.AccountManagement.ADStoreCtx.ResolveCrossStoreRefToPrincipal(Object o)
   at System.DirectoryServices.AccountManagement.ADUtils.DirectoryEntryAsPrincipal(DirectoryEntry de, ADStoreCtx storeCtx)
   at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.get_CurrentAsPrincipal()
   at System.DirectoryServices.AccountManagement.FindResultEnumerator`1.get_Current()
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.d__aa`1.MoveNext()
   at Continua.Membership.Ldap.LdapGroup.GetMembersWithInheritanceGroups(GroupPrincipal group, Boolean includeInheritedGroupName)
   at Continua.Membership.Ldap.LdapGroup.RetrieveAll()
   at Continua.Membership.Ldap.LdapSynchronizer.Execute()

2) I added base groupsContainer -attribute to the configuration:

<authentication mode="LDAP" fqdn="ourdomaincom" administratorsGroup="Build_Admins" groupsContainer="DC=OURDOMAIN,DC=COM"/>

When the service was started using this configuration an exception was output to the system event log:

 Could not synchronize with Ldap domain ourdomain.com' and groups container DC=OURDOMAIN,DC=COM. Getting all ldap groups
Sync status : While trying to resolve a cross-store reference, the target principal could not be found in the domain indicated by the principal's SID.
Synchronization will be attempted again in 30 minutes.

The stack trace appears to be identical to the initial exception.

3) I added the correct groupsContainer -attribute to the element.

<authentication mode="LDAP" fqdn="ourdomain.com" administratorsGroup="Build_Admins" groupsContainer="OU=Groups,DC=OURDOMAIN,DC=COM"/>
 

When using this configuration, the service does not emit any exceptions to the event log, but all login attempts with accounts belonging to the build_admins -group result in being redirected to url

 /account/unauthorised

stating that "

The page you requested required permissions that you do not have, you can choose to login with an account that has the necessary permissions or go home.

"

 No log entries are emitted from the attempted logins.

New users who have not logged in before do not appear in the database.