Azure website password protection - azure

I would like to enable viewing a website that I created to one person, whose IP I do not know. Is there a way to hide the website under a simple password (without publishing the page and logging by Facebook etc.)?
Thank you!

If the person can have an account in an active directory you trust, you can add them pretty easily.
https://learn.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication
Only users that have access to the AAD (including guests) can see the site afterwards.

Related

How to disable MediaWiki user account from the wiki website as an administrator

I'm the administrator of a wiki that's only accessible via login from a user with an account. I need to remove/disable/delete a user, but from the special pages on the website, I only seem to be able to delete their contributions and block the user. What I want is to prevent the user from ever being able to login and I've seen a few solutions such as changing their password and merging his account with someone else but those options seem to be accessible only via the Mediawiki software, which I've been having trouble installing. So is there any way to do this on the website itself?
Set $wgBlockDisablesLogin to true and block the account.

Always prompting of log in information for users

I have a requirement to always prompting of log in information for users in SharePoint site rather than taking their logged in credentials.
Any idea??
Depending on the setup you have.
You could just remove the SharePoint site from the trusted sites or local intranet under IE's security tab using a group policy.
This will cause a prompt every time they go to the site.
you need to reverse the steps found here
Regards,
Vince

How to get users to login twice in SharePoint 2010?

I have somewhat of an odd question (for me, at least).
We have some private information a department would like to place on our SharePoint farm. The problem is, this is very sensitive information, and law demands that we have a 'two-stage' login process to secure the data.
Currently, it is housed using a system that:
A) you have to login to our network (windows logon screen)
B) you have to login to the application.
Our SharePoint farm has integrated authentication enabled. Meaning, once you login to your computer in the morning, you never have to login to sharepoint as it already knows your credentials.
This is a problem for us. Can we enable some sort of custom Sharepoint login?
Will this require a new web app for the site? A new site collection only perhaps?
Thanks,
~~Kolten
What you are looking for is called forms based authentication. Sharepoint 2010 uses claims based authentication and one of the providers you can configure is forms based. Meaning they provide a user name and password.
Here is a tutorial with the steps to do, it is a relatively straight forward process. just follow all the steps.
http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
If you move you site out of Intranet zone, then IE will automatically ask for credential everytime.
See this:
http://support.microsoft.com/kb/258063

Admin section for website - security?

Designing a user content website and the question is for the admin section, from a security point of view, where should it be placed?
same domain and allow admin to enter site like other users from signin form using admin email
Have a separate sub-domain only for admin login
Have a separate secret domain used to access admin features
or any other suggestions?
goal is prevent anyone from knowing about the admin section and to keep it locked as much as possible.
Thanks
Actually I work on a system that uses a separate subdomain, and there's a whole another ASP.NET project dedicated for the Admin section of the parent domain.
This has many advantages for us. Some of them are:
Completly different authentication mechanism for one site and the other.
We can deploy the website without shutting down the admin site and viceversa.
Well, as a basic rule, I'd say it doesn't really matter. Your login form needs to be secure, whether it's exposed or not.
However, I understand the desire to keep the admin area hidden in any case. I personally like this variant the best:
same domain and allow admin to enter site like other users from signin form using admin email
because it doesn't leave any traces on the client computer that are easily detectable (like "admin.example.com" or "example.com/super-secret-admin-area").

Viewing a MOSS 2007 page as another user would see it - without logging in as that user

In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.

Resources