Can SDL Tridion, by default, talk to the active directory based on the domain of the server where Tridion is installed?
o Ex: we install tridion in the server server1.abc.com where abc.com is my domain
If it cannot be done by default, can you please let me know how we can configure it?
Yes it can be done - this is the default behavior.
In the Add User dialog you should be able to type a domain name, and if the server (and the server's user account, MTSUser by default) is allowed to talk to that domain you'll get a list of the users and you can add them to the list of allowed Tridion users.
Nothing to configure unless you want LDAP integration.
Related
For a client, we have to connect a WSO2IS 5.10.0 to an Active Directory.
For that we have created a secondary user Store with this configuration:
User store main configuration
User store optional configuration
User store advanced configuration
WSO2IS can connect to Active Directory as we can retrieve users and roles.
Before doing any claim mapping we have tried to edit and create user without any problems.
And then we have mapped some claims to retrieve more information from Active Directory.
And here come our problems:
We can't create a user in Active Directory
We can't update a user in Active Directory
This two problem gives us this error :
Caused by: javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090C45,
comment: Error in attribute conversion operation, data 0, v1db1
Things that we have tried:
Check (and check a second and third time) that all our claims are mapped correctly (and they are)
Reset all claims to default mapping (on the state where we where able to create/update user)
Set User DN Pattern (as explained here)
Restart on a fresh instance of WSO2IS 5.10.0
But all things that we have tried are not helping and we are stuck.
Any help would be hugely appreciated. Thank you for any suggestions.
As asked, this is the AD attribut we have mapped :
sn
givenName
cn
displayName
name
description
mail
sAMAccountName
userPrincipalName
accountExpires
pwdLastSet
userAccountControl
scriptPath
homePhone
mobile
facsimileTelephoneNumber
title
department
company
Here the issue is LDAP_NO_SUCH_ATTRIBUTE returned from the AD.
We don't know which attribute is missing on AD side.
From the existing DEBUG logs of the server, probably you wouldn't be able to log all the attributes that WSO2 is going to update. Therefore, you have to choose an alternative option.
Manual check - Even though there are only few attributes configured (and verified) by you, there are other claims with default attribute mappings. Please check all the mapped attributes that are there in the http://wso2.org/claim dialect.
Remote debug - Remote DEBUG the server to check what are the attributes WSO2 is trying to write in to. (Smaller subset than previous approach) Then verify if those exist.
To do this remote debugging you can check out the Kernel source code from here.
To find out the correct tag to checkout, you can find the kernel version of your identity server version from this release matrix.
Once you clone and checkout the correct tag, you can use IntelliJ Idea or a capable IDE to remote debug the server as explained in the this blog.
Though it's hard to point an exact line of code, you can put DEBUG points to ActiveDirectoryUserStoreManager.doAddUser() and ActiveDirectoryUserStoreManager.doSetUserClaimValue() methods and start from there.
P.S. You can also check if the carbon log's stack trace contains any clue of the failing attribute or the respective claim, so that you can check validate it.
I'm currently using mod_authnz_ldap to enable HTTP Basic Authentication against Active Directory for a VirtualHost. Based on the documentation it is recommended to set a user and password to enable the resolving of user DNs for the bind.
However AD offers methods to bind users without using a separate account for searching the directory in front. E.g. you can suffix a username with the Domain like that: username#domain and AD resolves the DN behind the scenes.
As I don't want to create accounts for my web servers I'm curious if there is a way to configure Apache2 using mod_authnz_ldap or another module to bind against AD without using an search account.
You can take advantage of the supported Active Directory object name forms for a simple bind, and skip the search for a user's DN by using directive AuthLDAPInitialBindAsUser with module mod_authnz_ldap.
I can access my reports through
http://mymachine:808/Reports
or
http://localhost:808/Reports
but not
http://myhost.mydomain.com:808/Reports
even when I have myhost.mydomain.com map to 127.0.0.1 in the host file. It was keep asking user name and password, but the same user name and password works fine in other ways to access.
How to fix this?
Update
It prompts to type in user name and password, but just to pop up again. So there is no way to get into the page with the broken URL.
This is consistent in at least 2 browsers: Firefox 47.0, and Edge 25.10586.0.0
Also, I didn't have Report Manager installed, here is my menu of Reporting services configuration manager:
From the hint in comments the issues is in the Reporting Services.
I was using the default settings, but MSDN said you can have different authentication types. I checked my reportserver.config file and I was using NTLM. Change it to use basic authentication solves the problem.
My guess of the reason, is that the browser will send a "Host" property for every request, and as this is inconsistent with NTLM's "domain", so Reporting Services reject the authentication. However, when switch to basic authentication, it simply pass the credential to Windows, so now it accepts.
References:
Authentication Types in Reporting Services
How to: Configure Basic Authentication in Reporting Services
You could try adding a new URL for Report Manager. To do this
Open Reporting Services Configuration Manager
Select Report Manager URL
Click Advanced
Click Add to add details
Here's a screenshot to help.
I am checking SonarQube 5.4 and the latest LDAP plugin 1.5.1. There are however a couple of issues.
First. My AD account is majcicam. If I log in with it, it is correctly shown in the users list. However if I login with MajcicaM (note capital letters) another additional user is added to the list:
As you can see from the attached image. For every login that I do make, seems it is treated as case sensitive and thinks of it as a different user.
Second thing. Once I assign a group to my user, on the next login those settings are gone. Seems that they are not persisted.
Am I doing something wrong? Is this a bug? Are my settings messed up?
Thanks
Mario
No bugs here, just some subtleties about LDAP Plugin configuration and behaviour. :)
Case-insensitive login
Set sonar.authenticator.downcase to true when delegating authentication to an LDAP/AD server which is case-insensitive.
Group mapping behaviour
When group mapping is configured (i.e. you manually configured ldap.group.* or you use the windows authentication mode with lightweight AD config), membership in LDAP/AD will override any membership locally configured in SonarQube. LDAP/AD becomes the one and only place to manage group membership (and the info is fetched each time the user logs in).
I'm trying to restrict TeamCity users to members of a specific AD group (FNC_TEAMCITY_USERS). LDAP user synchronisation was already working. In my ldap-config.properties I changed this:
teamcity.users.filter=(objectClass=user)
to this:
teamcity.users.filter=(&(objectClass=user)(memberOf=CN=FNC_TEAMCITY_USERS,OU=Groups,DC=group,DC=ourdomain,DC=com))
I restarted the TeamCity service and this change had no effect. All AD users can still log in to TeamCity. I tried this on both our 6.5 instance and our 7.0 (EAP) instance.
Is there something I've missed or is this a bug?
The property limiting users who can login into TeamCity is "teamcity.users.login.filter". Try setting it instead of "teamcity.users.filter".
"teamcity.users.filter" is the one affecting users synchronization (particularly creating users in TeamCity for users in LDAP).
Be sure to have "java.naming.security.principal" and "java.naming.security.credentials" correctly specified as they are required for "teamcity.users.login.filter" use.