I have tried multiple times to get this to work, but I haven't figured it out yet, so I'm asking in here, hoping that someone will be able to help me out.
I am using Atlassian's Bitbucket, Jira and Bamboo and they're all synced with an AD. At the moment I am using my AD user to retrieve all the other users. It works, but it's not optimal, as the password expires every three months, and I have to change the LDAP user login info on all three applications. We have ordered a Service User, where the password doesn't expire, but the problem is that the Service User is in another group.
The picture below shows how the AD is set up. My Service User is in a group called Special Users. I would like to use this user as the login user in the settings. This way I would never have to think about changing password, when my AD password expires.
I would then like to retrieve all the users from the "Normal Users" group.
Let me know if more information is needed.
Thanks.
You could also add multiple user directories pointing to different parts of your Active Directory.
Jira has an internal Crowd out of the box.
You may let Jira connect to User directory and let all other application use Jira for authintication.
This would save time by only updating your LDAP password every 3 months on 1 application and reflected on all 3 applications
Related
Is it just me who's finding AD group is very complex? ;-(
I have a web service that only allows a certain number of role groups to have access. Say we allow people within role group 'rGroupA' to have access.
At some point, a user logs on to our web server, and we have the user name. However, we would not like to ask the user to type in the password.
Is it possible for us to know if this user belongs to 'rGroupA' somehow?
Currently, I could logon our LDAP server with my username and password and see the list of groups I am in. However, I could not search for the groups for my colleagues.
I have searched google for a while but haven't found the answer. It could be that I don't understand LDAP mechanism very well.
Many thanks!
One thing I do currently in an enterprise app is logon to a single admin email account that has delegation over other users and using delegation, we are able to manipulate email/calendar/contacts of users.
I'm looking to use the Microsoft Graph API and I have managed to use admin delegation and gain access to various resources, however last modified (on Onedrive/Sharepoint) is showing the app instead of an individual user.
I understand I can use Oauth and logon as individual users, capture a token and then do what I need under the context of that user, but, I need to do this server side where tasks run. Is there anyway to use admin approved delegation/impersonation from the app so that the users don't have to signin?
e.g. standard that works:
https://graph.microsoft.com/v1.0/sites/my-site.office.com/drive/root:/file.txt:/content
Looking to add a user tag, but this doesn't work:
https://graph.microsoft.com/v1.0/user/{id-of-user}/sites/my-site.office.com/drive/root:/file.txt:/content`
After searching for ages, the closest I have read seems to be in here however, I was wondering if there was a standard way of doing this - I haven't been able to get the JWT part of this working (and not sure if this is even the correct thing I am looking for).
I'm trying to use WSO2IS with an Active Directory LDS.
Using the store to display and read users is no problem.
However when editing a user, there's a hiccup.
The users are situated in OUs in the AD and in the synced AD LDS.
(We use the AD LDS to add user attributes without changing the original AD.)
When I edit a user it will be moved by the IS to the UserSearchBase.
IS is still able to show the user - for now.
When the AD LDS is synced with the AD, the user will be moved back to its original OU.
The IS will not be able to find the user, because it is still looking for the user in the "new" location in the UserSearchBase root.
Only if I restart the IS, the user will be found again.
I tried to recreate the behaviour by hand:
Create user in an OU situated in the UserSearchBase
Edit the user with IS
Move the user back to its original location in the OU in the AD
IS throws error
Is there a way to tell the IS to leave the user DN/location as is?
Is there a way to disable caching? (Without impact on performance?)
Regards,
Mat
This looks like a known issue with Cache Expiry Bug 6471. Please see if the description matches your exception trace.
There is a fix going on for the above. That will be available on future release.
You can also build from the public repository once the fix is done, if this is the case.
Workaround
You can edit and save the user store, if his user store is configured with the UI. You do not need to change any value. This will cause a new instance to be created, thus re-creating the cache.
I have a Asp.net MVC application that uses Azure AD and OpenID Connect OWIN middlewares to handle authentication. Everything works fine except for one thing : if a user is already logged-in on another Microsoft Application lets say a Office 365 account or maybe a live mail account, when trying to login it recives a page saying that it is not allowed to log into my app, which is correct, but some how I need to catch that situation in my code to allow the user to sign in with a different account. Is there a way of doing that? This is by design? I mean : the user have to log in only with a live/azure account at the time ? I couldn't find any documentation about this.
As of today there is typically one user at a time, but we will soon support for you a way to select a specific user instead of automatically signing you in with the most recent one.
One way you can work around this today is by injecting the parameter "prompt=login" in your sign in requests. You can do that in the RedirectToIdentityProvider notifications, similarly to what is showin in http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/ for domain_hint. This will cause the sign in experience to always start with a fresh prompt even if the user is already signed in. The draw back is that you'll never get SSO this way. Hopefully our account switiching feature will become available soon, keep an eye on http://blogs.technet.com/b/ad/ for announcements
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.