Jump to content
Plastic SCM forums are now in Unity. Click here to open the new forum ×

LDAP Authentication problem

geoff5777

By geoff5777
in Community Edition

Recommended Posts

geoff5777 Newbie

geoff5777

Posted
Posted

I have configured plastic server to use active directory and also configured client to use AD as well. This configuration is working fine.

Because my home computer is not part of the corporate domain I configured it to use LDAP authentication. The server is still configured as AD.

When I use the Test Connection function the message "Active Directory or LDAP: Invalid credentials username, password or domain are not valid" is displayed.

On the basis that there may be some issue with the VPN I changed my work computer (which was already successfully authenticating with AD) to use LDAP instead. When I use the Test Connection function I get the same message.

I would be grateful for any assistance.

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Thanks Manu for your response. ADExplorer looks like a very useful tool.

The user and password are fine; I use the same credentials to log onto windows every morning.

I think the issue might be related to the following:

1. The windows server running Plasticd is in a SERVERS domain.

2. The client machine and client users are in a USERS domain.

ADWorking mode is quite happy with this arrangement, however LDAP definitely isn't.

I've tried the following username formats in the LDAP connection dialog and none work:

1. geoff5777

2. USERS\geoff5777

3. cn=geoff5777

4. cn=USERS\geoff5777

5. geoff5777@USERS

Perhaps the LDAP provider is looking in the SERVERS domain for a user that is in the USERS domain?

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Yes, client works if both server and client are configured as AD.

If server is configured as AD and client as LDAP then it doesn't work.

Since my last message I have found that if the server is configured as LDAP (server type set to AD) then the client will work if configured as either AD or LDAP.

I guess this is because we can set the server to the required domain. Perhaps this is the solution we are after.

Also, I set up a test Ptastic server in the USERS domain configured as AD. If client is AD then it works, if client is LDAP then it doesn't work.

I am more and more convinced that my problem may be caused by our complicated domain structure.

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

I suspect you may be right about the LDAP provider.

We need to be able to connect from home as well as at work so a pure AD configuration is not possible.

However we now have a working solution. We only have a few users so maintenance will not be a problem.

I should explain that the reason we have such a domain structure is because we have an external service provider to maintain desktop computers and file and print servers, and an internal provider to manage web and database servers,

Here's a suggestion for you: How about allowing AD or LDAP as authentication providers but have plastic itself be the group provider as in UP mode?

Thankyou for your time and assistance,

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Ok, so we kept this configuration (server configured as LDAP with server type set to AD, client set to AD) and all appeared to work happily.

This morning I arrived at work to find the test server with a 100Mb log file and plasticd flogging the cpu 100%.

The production server had a 60Mb log file and the cpu was behaving, but while I was watching the cpu on this server also shot to 100%.

Memory usage was of the order of 1Gb, whereas normally it is around 30Mb I think.

It seems that the ldap provider is querying the AD every few minutes.

In less than a 24 hour period, the server used over 3 hours(!) of cpu time.

Needless to say we switched the server back to AD immediately.

Of course, we can no longer connect from home using an LDAP client.

Is there any logging we can enable to help us see the interaction between the LDAP client and the AD server?

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Sure!

Open the "loader.log.conf" file you will find in the Plastic SCM server directory.

Add the following appender:

 <appender name="AuthAppender"
   type="log4net.Appender.FileAppender">
  <file value="auth.log.txt" />
  <appendToFile value="true" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date %thread %property{UserID} %property{TransactionID} %property{ClientMachine} %-5level %logger - %message%newline" />
  </layout>
 </appender>

And add the following loggers (check for duplicates):

 <logger name="Codice.CM.SEIDInfo.NetWorkAPI">
   <level value="DEBUG" />
   <appender-ref ref="AuthAppender" />
 </logger>

 <logger name="ADProvider">
  <level value="DEBUG" />
  <appender-ref ref="AuthAppender" />
 </logger>

 <logger name="LdapProvider">
 <level value="DEBUG" />
 <appender-ref ref="AuthAppender" />
 </logger>

Restart the server and review if the file is created and what's logged. Share with us the results.

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Firstly, our problems with plastic server in LDAP configuration closely resemble this: http://www.plasticsc...-memory-issues/

It is not clear if there was a resolution for this issue.

Now with plastic server in AD configuration and client in LDAP configuration...

I doctored loader.log.conf as described and it didn't produce much in auth.log.txt, only this: auth.log.txt

After a bit of research, I managed to get some more verbose logging into the main log file, however. plastic.server-2.txt

Hope it helps.

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Dis you set the log level to DEBUG? Only one log line... It's strange.

Yes, the problem you link is similar than the one you are facing, but we weren't able to reproduce the issue. If you want we can schedule a GoToMeeting session in order to get more information from your scenario.

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Yes, the log level was DEBUG. I copied the text off this page.

I have here a couple of relevant entries I found in the Windows Security log.

The first is where I type the user name in the form DOMAIN\UserId, the other is where I just type UserId.

SecurityLogEntries.txt

The log entry was Audit Success, so I suppose that means that your provider was successful even though the message says 'attempted'.

Hopefully this will give you some more clues.

I am happy for a GotoMeeting session to happen, but see how you go with this info.

We seem to have an 8.5 hr time difference.

Btw, what product do you guys use for issue tracking?

Link to comment
Share on other sites
RetroSonic Newbie

RetroSonic

Posted
Posted

Hello,

I hope you don’t mind if I add something since it looks like I ‘m facing the same problem (with a slight twist that hopefully could shed some light). I have the following setup:

- Server: Windows 2003 r2, domain controller, SQL Server 2008 R2, Active Directory Integration

- Workstation: Windows 7, domain member, SQL Server CE, Active Directory Integration

- Laptop: Windows Vista, NOT member of domain (although user name and password match a domain user), SQL Server CE, Local Users

In order to connect from the laptop to the server I set up an additional profile with LDAP authentication which, in the same way that geoff5777 described, it fails. However (and this is the most STRANGE), if I use LDAP to connect from the laptop to the workstation, it WORKS!!

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Hi RetroSonic,

I tried a scenario similar to your description, but didn't have a matching userid and password on my 'laptop' (which is actually my home computer).

However, in a round about way you gave me an idea.

I changed the plastic server running on my work computer (which is in the USERS domain) to run as Network Service user, but still configured as AD,

Lo and behold, the LDAP client on my home computer got a successful connection !

Sadly, when I tried the same thing on our test server (which is in the SERVERS domain) I didn't get the same successful result.

So, its back to you, Manu. I hope this information is of assistance.

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Hi geoff,

I try to have time to test the scenario, I'm afraid about the performance issue with the mode you mention.

Can you please tell me your timezone?

Btw, what product do you guys use for issue tracking?

We use our own home made bug tracking system, we call it "TTS", we're discussing to open source it.

Link to comment
Share on other sites
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Hi Manu

We are in GMT +9:30.

Just to be clear, our preferred solution is to have our servers and domain clients in AD configuration, and the non-domain clients (home computer) in LDAP configuration.

Now that changing the plasticd service user on my work computer to Network Service has allowed a successful LDAP connection, I am convinced that the problem relates to the users and the servers being in different domains.

Link to comment
Share on other sites
  • 2 months later...
  • 3 weeks later...
geoff5777 Newbie

geoff5777

Posted
  • Author
Posted

Some notes on our situation which may be of use.

 

1.  Our work client computers and users are in a USERS domain while the server hosting plasticd is in a different domain (SERVERS).

2.  Home computer is either not in a domain or is in a HOME domain which I have set up for testing.

3.  Work client computers and plastic server were originally configured as AD and this configuration worked as expected.

4.  Because my home computer (connected via VPN) is not in the USERS domain the client has to be set to LDAP.

5.  IMPORTANT:  Because the users and clients are in a different domain, the plastic server was unable to authenticate an LDAP client using AD credentials !!!

6.  We therefore changed the plastic server to LDAP authentication with settings so it would authenticate to the USERS domain.

7.  To do this you need to configure plasticd with a domain user.  This should be a user created specifically for running plastic because if you use your own user id and the password expires then the plasticd server won't work any more!  Not sure why, it might be an LDAP thing.  (Manu you may wish to comment on this item)

8.  The work client computers were able to remain as AD authentication.

 

Unfortunately I have not had the opportunity to test thoroughly over the VPN, but the initial testing indicates that this configuration works well.

Performance over the VPN (ADSL2) is a bit rubbery (nothing like being on the corporate network) but is certainly adequate. 

I should also note that our earlier problems with cpu and memory hogging on the server have been resolved.  We are now on server version 4.1.10.394.

 

Hope this helps.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...